Πόλη σωστή τοποθέτηση. Ελπίζω να ικανοποιήθηκε ο Kelman. Απλά δεν συμφωνώ ( επειδή το ανέφερες) το ότι η CSLA – είναι αρχιτεκτονική που δημιουργεί objects από table σε βάσης. Σίγουρα υπαρχή code generator για CSLA κλάσης (οπός και για enterprise library κλπ) αλά το CSLA είναι (κατά τι δίκη μου ταπεινή ερμινια) αρχιτεκτονική που σου επιτρέπει να γράψεις κάπου το business logic της εφαρμογής και αυτά τα object να υποστηρίζουν data binding (αλά δεν ασχολιέσαι με το να μετάφερες τα δεδομένα προς και από Windows η Web Forms) + το ότι επιτρέπουν scalability (δηλ μπορείς να χρησιμοποίησες αυτά τα object είτε local, είτε μέσο remoting, IIS η Enterprise Library)

Εν μέρει
Απλά, η εντύπωση που έχω και ήθελα να επιβεβαιώσω (ή να απεμπολίσω) είναι ότι σε μεγάλο ποσοστό των περιπτώσεων, η επιλογή της όποιας αρχιτεκτονικής μέσα στο όλο οικοδόμημα ενός application είναι buzzord-driven/magazine-driven/hype-driven. Ότι συνήθως δεν γίνεται research σε εναλλακτικές αρχιτεκτονικές ώστε να επιλεχθεί η καταλληλότερη βάσει προδιαγραφών που θα έχουν τεθεί εκ των προτέρων, κλπ. Ότι συνήθως τα διάφορα "R&D" τμήματα των εταιρειών κάνουν πολύ D και λίγο R.

O Anjelinio το είπε στην απάντησή του:

Προσωπικά, σπάνια βρέθηκα στην ευτυχή θέση να έχουμε το χρόνο να δοκιμάσουμε ένα-δύο approaches προτού πάρουμε τελική απόφαση. Συνήθως είναι πολλοί external παράγοντες που επηρρεάζουν ... ( βλέπε "το θέλω χτές" ) ... οπότε ... κάνεις ότι μπορείς να κάνεις, όσο πιο καλά μπορείς με τα δεδομένα constraints.

Περίμενα να δω κι άλλες τέτοιες απαντήσεις.

---

Vir prudens non contra ventum mingit

Αν θέλεις τη δίκια μου ταπεινοί άποψη ούτε αυτό που λες ισχύ. Η πιο πάλες εφαρμογές γράφονται χωρίς καμία αρχιτεκτονική. Απλά πιάνουμε το Visual Studio ( ι το οποιοδήποτε άλλο) και κλικ από εδο κλικ από εκεί γίνονται τα θαύματα¨)

Όσον αφορά το CSLA.NET framework η αλήθεια είναι ότι δεν ακολουθεί ούτε καθαρά Table Module αρχιτεκτονική ούτε όμως και Domain Model. Ναι μεν, τα business objects δεν είναι υποχρεωμένα να ακολουθούν το σχήμα της βάσης, αλλά όσο διαφέρουν από τη βάση, τόσο δυσκολότερη είναι η χρήση της. Ή μάλλον, χωρίς code generator που θα δημιουργήσει τα κατάλληλα stored procedures και objects, η δημιουργία των αντικειμένων είναι σχετικά επίπονη. Επιπλέον, κάθε business object στην CSLA.NET περιλαμβάνει κώδικα που καλύπτει όλα σχεδόν τα layers, από UI με το databinding και τα validation rules, μέχρι τη βάση μέσω του Data Portal. Αυτό κάνει τα αντικείμενα μάλλον βαρειά, οπότε δεν είναι και τόσο εύκολο να δημιουργήσει κανείς ένα Domain Model.

Σχετικά με το ότι οι παλιές εφαρμογές δεν έχουν αρχιτεκτονική, μάλλον είναι υπερβολική η γενίκευση. Όταν ξεκινάει μία εφαρμογή, κατά κανόνα έχει αρχιτεκτονική, έστω και αν σε αυτή αφιερώθηκαν μόλις 2 ώρες. Μέσα σε μερικούς μήνες όμως, η αρχιτεκτονική έχει ξεχαστεί και ο καθένας γράφει ό,τι τον βολεύει. Αν μάλιστα η εφαρμογή "ζει" για αρκετό καιρό, με συνεχείς τροποποιήσεις ανά πελάτη και συχνές αποχωρήσεις προγραμματιστών, η αρχική αρχιτεκτονική εξαφανίζεται από τις προσθήκες. Είναι κάπως σαν την αρχιτεκτονική της Αθήνας πριν και μετά τον πόλεμο.

Ακόμα πιο συχνό φαινόμενο είναι να χρησιμοποιηθεί μία αρχιτεκτονική για μία πρώιμη έκδοση της εφαρμογής και μετά να "φουσκώσει" αυτή για να καλύψει νέους πελάτες. Φτιάχνουμε π.χ. μία εφαρμογή για ένα διαγωνισμό ή ένα πελάτη, και αφού είδαμε ότι δούλεψε χρησιμοποιούμε τον ίδιο κώδικα και σε άλλους, προσθέτωντας ότι λείπει με τον ίδιο τρόπο που φτιάχτηκε η πρώτη έκδοση. Μόνο που σύντομα η αρχιτεκτονική που φτιάχτηκε για ένα μικρό πελάτη αρχίζει να "τρίζει" κάτω από το βάρος των προσθηκών, χωρίς να σημαίνει ότι η αρχιτεκτονική ήταν λάθος για τον αρχικό πελάτη.

Ένα τέτοιο παράδειγμα είναι η ίδια η CSLA.NET, αλλά και όποια αρχιτεκτονική βασίζεται σε hard-coded αντικείμενα. Είναι καλή όταν δημιουργείται μία εφαρμογή από το μηδέν, δεν μπορεί όμως να καλύψει διαφορετικές απαιτήσεις για διαφορετικούς πελάτες. Οι νέες απαιτήσεις απαιτούν τροποποιήσεις στον υπάρχοντα κώδικα. Αν κάποιος θέλει να καλύψει αυτές τις περιπτώσεις θα πρέπει να χρησιμποιήσει μία αρχιτεκτονική που θα επιτρέπει το δυναμικό προσδιορισμό του domain model και τον ορισμό των busines processes.

Ίσως ένα παράδειγμα να κάνει πιο κατανοητό το διαχωρισμό. Αν θέλω να φτιάξω μία λογιστική εφαρμογή, θα χρησιμοποιούσα CLSA.NET. Τα business objects αλλάζουν σπάνια χαρακτηριστικά, ενώ η αλλαγή στους νόμους και τους κανονισμούς μπορεί άνετα να καλυφθεί αλλάζοντας τις κατάλληλες μεθόδους στα αντικείμενα. Αν όμως θέλω να φτιάξω μια εφαρμογή ERP ή μία σοβαρή εφαρμογή e-Commerce, δεν μπορώ να αλλάζω τα αντικείμενα κάθε φορά που πάω σε άλλο πελάτη!

---

Παναγιώτης Καναβός, Freelancer
Twitter: http://www.twitter.com/pkanavos

Όλη αυτό θέλουμε (να μην αλλάζει ο κώδικας από πελάτη σε πελάτη) αλά η μεγάλη ερώτηση είναι πως. Δεν νομίζω ότι έχει δοθεί από κοπιών η απάντηση – απλά το παλεύουμε.

Όσο αφόρα την άποψη μου για τις παλιές εφαρμογές ήταν μια προσωπική οπτική. Θα είχε ενδιαφέρων να καταθέσουν εμπειρίες από άτομα που έχουν ασχοληθεί σε διάφορα project για να έχουμε μια άποψη από πρώτο χέρι. Φυσικά για μένα δεν μπορεί να θεωρηθεί αρχιτεκτονική κάτι που συμφωνήθηκε σε ένα μιτινγκ 2 ωρών και μετά δεν ακολουθήθηκε από κανέναν.

Και κλείνοντας με την CSLA. Δεν είναι η αρχιτεκτονική που είμαι ο φανατικός οπαδός της (οπός καμία άλλη – απλά προσπαθώ να μάθω από τους guru:)). Απλά την ανέφερα. Αλλά δεν σύμφωνο μαζί σου ότι είναι βάρια η είναι δύσκολο να κτίσης Domain Model – είναι τόσο εύκολο η τόσο δύσκολο όσο με οποίαδίπoτε άλλη. Φυσικά είναι πιο βάρια να χρησιμοποιήσεις databinding από το να κάνεις απευθείας μεταφορά των δεδομένων από και προς το UI – αλλά γράφεις λιγότερο κώδικα. Η τελική επιλογή είναι δική σου….

Συμφωνώ με τον pkanavos, κάθε πρόβλημα χρειάζεται διαφορετική αντιμετώπιση. Το αρχικό ερώτημα ήταν σε επίπεδο αρχιτεκτονικής, νομίζω δικαιολογημένα έχει προκαλέσει αυτόν τον ντόρο το SOA, σε ένα project που δουλεύουμε περίπου για ένα χρόνο.. με windows forms και smart clients, έχουμε εφαρμόσει Service Oriented αρχιτεκτονικές, που νομίζω είναι ένα βήμα παραπάνω απο το Object Oriented.. και ότι παρουσιάζει το CSLA ( το οποίο δεν περιφρονώ καθόλου). Στο συγκεκριμένο project έχουμε χρησιμοποιήσει Typed Datasets, τα οποία βρίσκω πολύ βολικά (sorting ordering.. κτλ) και custom μηχανισμό για το Data Access Layer με αποκλειστική χρήση stored procedures. Γενικότερα δεν πιστεύω στις έτοιμες λύσεις (ίσως και με κάποια προκατάλειψη) των ORM.

Πρόσφατα διάβασα ένα βιβλίο Service-Oriented Architecture : A Field Guide to Integrating XML and Web Services, νομίζω είναι ένα πολύ καλό reference για SOA (αν έχετε κάτι άλλο να προτείνετε..)

Το SOA δεν έρχεται σε αντιπαράθεση με το ΟΟ.

http://www.lhotka.net/weblog/SOACSLANETAndTrustBoundaries.aspx

Τώρα το άμα είναι ένα βήμα παραπάνω δεν το γνωρίζω…

Παναγιώτη το παραπάνω ήταν χείμαρρος! Λοιπον, θα μου άρεσε να το έβλεπα σαν ένα blog post ή σαν ένα αρθράκι...τι λες; :)

---

Σωτήρης Φιλιππίδης

DotSee Web Services

Έχω ένα blog post υπόψη. Ο τίτλος θα είναι κάτι στο στυλ "The architecture that wasn't" ή κάτι τέτοιο. Ήθελα να βάλω το "Ο κόσμος το 'χει τούμπανο κι εμείς κρυφό καμάρι". Το θέμα θα είναι μία πολύ διαδεδομένη αρχιτεκτονική (full αρχιτεκτονική, όχι απλά επιλογή data access mechanism), η οποία χρησιμοποιείται και στην Ελλάδα πολύ. Έχει όμως μερικά περίεργα χαρακτηριστικά:

• Χρησιμοποιείται πάνω από μία δεκαετία γενικώς
• Όσοι την εφαρμόζουν εντός Ελλάδος νομίζουν ότι κανείς άλλος δεν το κάνει.
• Όταν μαθαίνουν ότι το κάνουν και άλλοι παθαίνουν σοκ.
• Όσοι την εφαρμόζουν εκτός Ελλάδος το κρατάνε μυστικό
• Επιτρέπει τη δημιουργία εντελώς νέων εφαρμογών μέσα σε μήνες (~6 για πολύ περίπλοκες εφαρμογές)
• Όσοι δεν την εφαρμόζουν νομίζουν ότι αυτό είναι αδύνατο, ακόμα και όταν βλέπουν τις εφαρμογές να δουλεύουν μπροστά στα μάτια τους.
• Όσοι την εφαρμόζουν, δεν καταλαβαίνουν γιατί δεν την εφαρμόζει όλος ο κόσμος. Αφού αυτοί καταφέρνουν να βγάζουν νέες εφαρμογές σε μήνες!
• Η Microsoft μας την δίνει σχεδόν τσάμπα. Του χρόνου θα είναι και σχεδόν εντελώς τσάμπα

Και μετά σκέφτομαι ότι θα ήταν καλό να κάνουμε και ένα community event ή ακόμα και DevDays όπου θα μαζευτούμε όσοι την έχουμε χρησιμοποιήσει στο παρελθόν και θα παρουσιάσουμε τις υλοποιήσεις μας, τα διαφορετικά χαρακτηριστικά που είχε ο καθένας, τα προβλήματα που αντιμετωπίσαμε. Έχω υπόψη τουλάχιστον 4 εταιρείες που την εφαρμόζουν.

Όχι τίποτε άλλο, να πάψουμε να ακούμε ότι όλα πρέπει να γίνονται σε φόρμες γιατί δεν προλαβαίνουμε και οι αρχιτεκτονικές είναι μόνο για τη Microsoft και εδώ είναι Ελλάδα και καλά όλα αυτά αλλά δεν δουλεύουν πρακτικά ... τον γνωστό εξάψαλμο.

---

Παναγιώτης Καναβός, Freelancer
Twitter: http://www.twitter.com/pkanavos

Και μια και ξαναξεκίνησε αυτή η κουβέντα, να πω και γιατί δεν μου πολυαρέσει η CSLA.NET. Απαιτεί τα αντικείμενα να κληρονομούν από δικά της συγκεκριμένα αντικείμενα, τα οποία κουβαλάνε πολλά μπαγκάζια. Φορτώνουν facilities για databinding, undo, serialization, υποτυπώδες validation και κάμποσα άλλα. Αυτό δεν είναι απαραίτητα κακό, αν μπορείς να επιλέξεις ποιές από αυτές τις δυνατότητες θέλεις και ποιές όχι. Δυστυχώς, έτσι όπως είναι γραμμένη η CSLA.NET αναγκάζεσαι ντε και καλά να κουβαλήσεις το σύμπαν. Επίσης, ο κώδικας κουβαλάει κατάλοιπα της VB6, όπως π.χ. utility μεθόδους Let, Get για να μπορεί ο συγγραφέας να μεταφέρει τον παλιό του κώδικα χωρίς μεγάλες αλλαγές.

Ο λόγος που η CSLA.NET σε αναγκάζει να κουβαλήσεις το σύμπαν είναι ότι για να προσθέσει κάποια λειτουργία ο συγγραφέας, κάνει inherit από μία base class που υλοποιούσε μία άλλη λειτουργία. Έτσι, π.χ. το BindingObject κάνει inherit από το Undoable object. Αν για οποιοδήποτε λόγο δεν θέλεις να χρησιμοποιήσεις κάποιο από αυτά (π.χ. θέλεις να έχεις το δικό σου validation αντί για το περιοριστικό της CSLA.NET, ή δεν θέλεις το undo) θα πρέπει να βάλεις χέρι στον κώδικα της βιβλιοθήκης. Αυτό δεν είναι καθόλου μα καθόλου καλό.

---

Παναγιώτης Καναβός, Freelancer
Twitter: http://www.twitter.com/pkanavos

Καλά, όλα μισά τα γράφω σήμερα. Ήθελα να συμπληρώσω πριν και ποιός θα ήταν ένας πολύ καλύτερος τρόπος από αυτόν που χρησιμοποιεί η CSLA.NET.

Ένα πολύ καλύτερο μοντέλο είναι η χρήση dependency inversion και providers, όπως π.χ. δουλεύει η ASP.NET και η Enterprise Library. Αντί να απαιτείς κάθε αντικείμενο να κάνει inherit από ένα base αντικείμενο το οποίο σου φορτώνει ένα κάρο facilities, απαιτείς απλά να υλοποιεί τα απαιτούμενα interfaces. Μετά, περνάς τα κατάλληλα provider αντικείμενα στις κλάσεις που δημιουργείς. Π.χ. φτιάχνεις αντικείμενα SerializationProvider, ValidationProvider, UndoProvider, BindingProvider και κάθε φορά που δημιουργείς ένα persistent object του δίνεις τους providers που θέλεις να χρησιμοποιήσει. Με τον τρόπο αυτό, αν θέλεις να αλλάξεις το validation ή να μην χρησιμοποιήσεις το undo, μπορείς να το κάνεις απλά, χωρίς παρεμβάσεις στην ίδια τη βιβλιοθήκη.

---

Παναγιώτης Καναβός, Freelancer
Twitter: http://www.twitter.com/pkanavos

pkanavos wrote:

Χρησιμοποιείται πάνω από μία δεκαετία γενικώς Όσοι την εφαρμόζουν εντός Ελλάδος νομίζουν ότι κανείς άλλος δεν το κάνει. Όταν μαθαίνουν ότι το κάνουν και άλλοι παθαίνουν σοκ. Όσοι την εφαρμόζουν εκτός Ελλάδος το κρατάνε μυστικό Επιτρέπει τη δημιουργία εντελώς νέων εφαρμογών μέσα σε μήνες (~6 για πολύ περίπλοκες εφαρμογές) Όσοι δεν την εφαρμόζουν νομίζουν ότι αυτό είναι αδύνατο, ακόμα και όταν βλέπουν τις εφαρμογές να δουλεύουν μπροστά στα μάτια τους. Όσοι την εφαρμόζουν, δεν καταλαβαίνουν γιατί δεν την εφαρμόζει όλος ο κόσμος. Αφού αυτοί καταφέρνουν να βγάζουν νέες εφαρμογές σε μήνες! Η Microsoft μας την δίνει σχεδόν τσάμπα. Του χρόνου θα είναι και σχεδόν εντελώς τσάμπα

Μιλάς για εκείνη την αρχιτεκτονική που όταν κανείς αναφέρεται σε αυτή σε κάποιο forum δεν την κατονομάζει;

---

Dimitris Papadimitriou Software Development Professional

Οι απαντήσεις παρέχονται για συγκεκριμένες ερωτήσεις και χωρίς καμιά εγγύηση. Διαβάστε επίσης τους όρους χρήσης.

Όχι, όχι γι αυτή. Αυτή δεν την είχα υπόψη καν! Το πιο σημαντικό στοιχείο είναι το 6, "Όσοι δεν την εφαρμόζουν νομίζουν ότι αυτό είναι αδύνατο, ακόμα και όταν βλέπουν τις εφαρμογές να δουλεύουν μπροστά στα μάτια τους." Άντε, να ρίξω άλλο ένα hint. Έχει να κάνει με metadata. Όχι "ολίγη από metadata". Full service meta.

---

Παναγιώτης Καναβός, Freelancer
Twitter: http://www.twitter.com/pkanavos

Ξέρεις πως τους λένε αυτούς τους ανθρώπους που κάνουν αυτό το πράμα ε;

---

Vir prudens non contra ventum mingit

Επιτρέπει τη δημιουργία εντελώς νέων εφαρμογών μέσα σε μήνες (~6 για πολύ περίπλοκες εφαρμογές)

Δηλαδή τη SAP σε πόσες μήνες την ξαναγράφεις