Χρησιμοποίησα CSLA.NET σε κάποιο project Και δεν μπορώ να πω ότι χάρηκα. H CSLA αναπτύχθηκε ως Business Objects για VB6 το 1997 και εξακολουθεί να έχει την ίδια δομή και περιορισμούς. Ακόμα και στη μορφή της για C# προσπαθεί να μιμηθεί την VB6. Στο αρχείο CSLA\Utilites.cs θα βρεις το παρακάτω μαργαριτάρι:
/// <summary>
/// Valid options for calling a property or method
/// via the <see cref="Csla.Utilities.CallByName"/> method.
/// </summary>
public enum CallType
{
/// <summary>
/// Gets a value from a property.
/// </summary>
Get,
/// <summary>
/// Sets a value into a property.
/// </summary>
Let,
/// <summary>
/// Invokes a method.
/// </summary>
Method,
/// <summary>
/// Sets a value into a property.
/// </summary>
Set
}
Και αυτό εν έτη 2008. Πέρα από αυτό, η CSLA.NET είναι χαρακτηριστική των αρχιτεκτονικών εκείνης της περιόδου, όταν νομίζαμε ότι το location transparency ήταν καλή ιδέα και ιδέες όπως το separation of concerns και modularity δεν είχαν ακόμα λαβει τη σημερινή τους μορφή. Παρόμοιες τεχνικές χρησιμοποιούσαν και οι πρώτες εφαρμογές J2EE πρωτού καταλάβουμε δεν ήταν scalable. Μερικά παραδείγματα:
- Τα αντικείμενα της μεθόδου είναι βαριά και περιλαμβάνουν proxy κώδικα που προσπαθεί να κρύψει το αν η επεξεργασία γίνεται στο desktop ή στον client. Αυτό όμως δένει τα αντικείμενα του client με αυτά του server. Ουσιαστικά, και στον client και στον server εκτελείται η ίδια κλάση.
Η αρχιτεκτονική αυτή είναι σχεδόν η αντίθεση των web services και του message passing.
- Τα διάφορα services όπως persistence, validation, binding, property change notifications, history/undo κλπ είναι δεμένα το ένα με το άλλο μέσω inheritance, με αποτέλεσμα να μην μπορείς να χρησιμοποιήσεις μόνο τα services που χρειάζεσαι Π.χ. το BusinessBase κληρονομεί από το UndoableBase αυτό από το BindableBase το οποίο περιέχει και τα property change notifications. Αν θέλεις να χρησιμοποιήσεις μόνο κάποια στοιχεία, ή να χρησιμοποιήσεις π.χ. το Validation block του Enterprise Library αντί για του CSLA, έχασες.
Γενικά, το CSLA είναι σχεδόν η αντίθεση του Aspect-oriented programming. Επειδή δένει πράγματα που στην πραγματικότητα είναι διαφορετικά aspects (πχ. undo και binding) κάνει πολύ δύσκολη την τροποποίηση του αν θέλεις να χρησιμοποιήσεις κάποιο διαφορετικό μηχανισμό από αυτόν που σου δίνει.
- Το Validation γίνεται ορίζοντας με κώδικα μία σειρά από delegates που θα πρέπει να κληθούν όταν αλλάζει ένα property. Αυτό όμως έχει πολλά προβλήματα: κατά κανόνα δεν ισχύουν τα ίδια validations και στον client και στον server, η αλλαγή των rules απαιτεί recompile των αντικειμένων και ουσιαστικά σχεδόν ολόκληρου του project, δεν είναι δυνατός ο ορισμός κανόνων εκτός των αντικειμένων π.χ. στον client. Αν ένα rule αφορά πολλαπλά properties, το rule πρέπει να δηλωθεί για κάθε property.
- Ο κώδικας δεν εκμεταλλεύεται τις δυνατότητες του Framework. Το παράδειγμα με τα Get, Let, Set είναι ίσως η χειρότερη περίπτωση, αλλά βλέπω ότι ακόμα και στην έκδοση για .NET 3.5 τα validation rules ΔΕΝ έχουν αντικατασταθεί από lamdas, αλλά εξακολουθούν να έχουν την ίδια χονδροειδή υλοποίηση.
Γενικά, δεν έμεινα ικανοποιημένος από την CSLA.NET. Προσπαθεί να καλύψει όλα τα επίπεδα μίας εφαρμογής, από τον client μέχρι τη βάση, αλλά το κάνει χρησιμοποιώντας τεχνικές της προηγούμενης δεκαετίας.
Παναγιώτης Καναβός, Freelancer
Twitter: http://www.twitter.com/pkanavos