Τώρα που EF στο .net 4.0 έχουν υποστήριξη για POCO, είναι δυνατόν τα business objects να μη έχουν γνώση για τον τρόπο με τον οποίο είναι stored η retrieved από στη βάση. 

Διαβάζω πως αυτό θεωρείται καλό, επειδή επιτρέπει την ένα διαχωρισμό των concerns, αλλά δεν έχω καταλάβει εάν είναι πάντα προτιμότερο η σε μονωμένες περιπτώσεις.   

Ήθελα να ρωτώ αυτούς που το έχουν δοκιμάσει τι αλλαγές απαιτεί ως προς τον τρόπο ανάπτυξη της εφαρμογής?

---

“Don’t worry if it doesn’t work right. If everything did, you’d be out of a job.”
(Mosher’s Law)

Αυτό είναι το νόημα τοων POCO στο EF 4, να μην γνωρίζουν και να μην εξαρτώνται από το Object Context.
Από όσο ξέρω θα υπάρχει στο EF 5 μια ακόμα ποιο βελτιωμένη έκδοση του POCO template.
Πιστεύω πως πάντα ο διαχωρισμός των Entities πρέπει να γίνεται κατα αυτό τον τρόπο ακόμη και στα μικρά projects.
Το ποιο σημαντικό που απαιτείται κυρίως είναι οτί πρέπει εσύ να διαχειριστείς πια το ChangeTracking το οποίο είναι σχετικά εύκολο
με μια - δυο τεχνικές (δες το Blog της Julie Lerman ή ακόμη πάρε το βιβλίο της).

Ακόμη δές το Selft Tracking Entities template το οποίο σε βγάζει απο την φασαρία και ειναι ObjectContext ignorant.
Θα σε σώσει απο αρκετή δουλειά πιστεύω.

---

Underwater:

Τώρα που EF στο .net 4.0 έχουν υποστήριξη για POCO, είναι δυνατόν τα business objects να μη έχουν γνώση για τον τρόπο με τον οποίο είναι stored η retrieved από στη βάση. 

Ήθελα να ρωτώ αυτούς που το έχουν δοκιμάσει τι αλλαγές απαιτεί ως προς τον τρόπο ανάπτυξη της εφαρμογής?

Για το ακριβές - δεν είναι σωστό να λέμε δεν έχουν γνώση για τον τρόπο που είναι stored ή retrieved, γιατί ποτέ δεν "είχαν" - δεν έχουν κώδικα που γράφει ο προγραμματιστής που τα φτιάχνει για να εκτελεί αυτές τις διαδικασίες.

Όλα τα υπόλοιπα δεν αλλάζουν - πάλι θα πρέπει να έχεις όλο το "support infrastructure" για να μπορέσεις να έχεις data-binding και validation, ανάλογα σε τι τεχνολογία θα είναι το User Interface της εφαρμογής σου.

Τάσκος Γιώργος:

Ακόμη δές το Selft Tracking Entities template το οποίο σε βγάζει απο την φασαρία και ειναι ObjectContext ignorant. Θα σε σώσει απο αρκετή δουλειά πιστεύω.

Ουσιαστικά, αν το παραπάνω μοντέλο ανάπτυξης έχει Domain Driven Developement στοιχεία, αυτό το μοντέλο, βοηθάει πιο πολύ σε web εφαρμογές, και θυμίζει το ActiveRecord pattern - κάθε φορά που έχεις μια σελίδα τα αντικείμενα που είναι επάνω σε αυτή το καθένα από μόνο του μπορεί να κάνει track το state που βρίσκεται...

 

George J.

---

George J. Capnias: Χειροπρακτικός Υπολογιστών, Ύψιστος Γκουράρχης της Κουμπουτερολογίας w: capnias.org, t: @gcapnias, l: gr.linkedin.com/in/gcapnias

George, το EntityState νομίζω το χρειάζεται το ObjectContext κυρίως για τα CRUD operations....έτσι δεν μένει μόνο σε Web εφαρμογές.

---

Τάσκος Γιώργος:

George, το EntityState νομίζω το χρειάζεται το ObjectContext κυρίως για τα CRUD operations....έτσι δεν μένει μόνο σε Web εφαρμογές.

Μην γινόμαστε δογματιστές - είπα βοηθάει περισσότερο, δεν είπα ότι κάνει μόνο για αυτό! Προσωπικά, και για WinForms εφαρμογή, αν είναι να υποστηρίξει κάποιος ένα table, ή το πολύ ένα parent-child relation, θα το πρότεινα ανεπιφίλακτα.

Από εκεί και πέρα, όταν έχουμε το parent να είναι 1-1 με άλλα 10 entities και το child να έχει 10 lookup tables και συμμετάσχει σε άλλα 10 parent/child relations σαν parent - και ένα απλό seller/company/client/order/order details/products/warehouse είναι ακριβώς ένα τέτοιο μοντέλο - δεν νομίζω ότι ένα τέτοιο μοντέλο μπορεί να προγραμματιστεί εύκολα χωρίς DDD προσέγγιση. Το Self tracking εκεί είναι σε μειονεκτική θέση, καθώς θα πρέπει να έχεις την έννοια της συνολικής εικόνας της δοσοληψίας (transaction) σε ένα άλλο επίπεδο, που θα πρέπει να αναπτύξει κάποιος...

 

George J.

---

George J. Capnias: Χειροπρακτικός Υπολογιστών, Ύψιστος Γκουράρχης της Κουμπουτερολογίας w: capnias.org, t: @gcapnias, l: gr.linkedin.com/in/gcapnias

Domain Driven Design
Οπως είπε παραπάνω ο φίλος μας Underwater
Separation Of Concern και άρα
Persistence Ignorance (decoupled from any specific persistence technology)
POCO Plain Old CLR OBjects (Δεν κάνει κανένα Reference σε συγκεκριμένο assembly  πχ. System.Data , System.Data.Entity)

 

Active Record
To active record δεν είναι Persistence Ignorant ακριβώς το αντίθετο, περιέχει το DataAccess
εσωτερικα ως μέρος της λειτουργίας του aggregate root.
Πχ. var order= order.Load(123);

Το μόνο κοινό που έχει το active Record με το Self-Tracking Entities
είναι ότι και τα δύο έχουν κάποιο μηχανισμό για να κρατάνε το State
για κάθε Child object και του aggregate root.

 

Σύγκριση

                                     Active Record | Self Tracking Entities
-----------------------------------------------------------------------------------

Persistence Ignorance                ΟΧΙ            ΝΑΙ
specific persistence technology     ΝΑΙ            ΟΧΙ
Testable                                  OXI            ΝΑΙ
Partially Loaded                         OXI            NAI               

 

 

H τεχνολογία Self Tracking Entities φτιάχτηκε μετά από αιτήματα προγραμματιστών για υποστήριξη σε
distributed objects.
Ένα παράδειγμα είναι η μεταφορά μέσω WCF Service στον client.

DataBindings

Τα Self Tracking Entities κάνουν implement to INotifyPropertyChanging και το INotifyPropertyChanged.
Τα collections κληρονομούν από το TrackableCollection που κάνει derive από το ObservableCollection.

Αυτά είναι αρκετά για να λειτουργήσουν τα DataBindings se WPF, Silverlight, ASP .NET WebForms, ASP .NET MVC.
To μόνο πρόβλημα που προκείπτει είναι με τα Winforms που για τα Databindings σε Collection κάνουν χρήση του
event ListChangedEventHandler ListChanged;
H microsoft αποφάσισε να αλλάξει τον τρόπο που κάνει notifications σε αλλαγές στα Collections και έτσι υπάρχει πρόβλημα
με τα databindings σε WinForms.

Κάνοντας όμως χρήση του BindingSource μπορούμε με κάποια WorkAround να λειτουργήσουμε κανονικά πχ. μετά από διαγραφή στο collection
τρέχουμε το  BindingSource.ResetBindings();

Θα μπορούσαμε να κάνουμε και implement to IBindingList στα TrackableCollection και να επιστρέφουμε ένα BindingList αντί για ObservableCollection.

Αν κάποιος περιμένει λίγο καιρό θα είναι διαθέσιμο στην επόμενη έκδοση. Η λειτουργία είναι ήδη διαθέσιμη στο Entity Framework CTP5.

Extensibility
Όπως γνωρίζουμε τα Self Tracking Entities γίνονται generated από ένα T4 template που μας δίνει την δυνατότητα να αλλάξουμε αρκετά την δομή
των οντωτήτων που παράγονται.

Μπορούμε να φτιάξουμε Partial Class και να προσθέσουμε κώδικα που δεν μπορεί να γίνει generated από το template.

Μπορούμε να κάνουμε implement to IDataErrorInfo και να παρέχουμε Validation Rules.

Μπορούμε να κάνουμε implement to ΙEditableObject για να κάνουμε Rollback Changes (Λίγο προσοχή στο changeTracking)

Αρχές του 2010 πήρα τον ρίσκο να αναπτύξω μια εφαρμογή ασύρματης παραγγελιοληψίας (Εστίαση)
Η εφαρμογή περιέχει πλήρη εμπορική διαχ. έχει δυναμική παραγωγή για τις αναλώσεις των ειδών.
Συγχρονίζει τα δεδομένα μεταξύ Υποκαταστημάτων και κεντρικού και με άλλα ERP της αγοράς.
Τα προβλήματα που αντιμετώπισα ήταν ελάχιστα.

Συστήνω τα Self Tracking Entities ανεπιφύλακτα, το μόνο πρόβλημα δεν υπάρχει αρκετό Documentation.

 

---

Μπλουγουράς Γιάννης
Wizcom O.E.

George J. Capnias:

Για το ακριβές - δεν είναι σωστό να λέμε δεν έχουν γνώση για τον τρόπο που είναι stored ή retrieved, γιατί ποτέ δεν "είχαν" - δεν έχουν κώδικα που γράφει ο προγραμματιστής που τα φτιάχνει για να εκτελεί αυτές τις διαδικασίες.

George J.

George,

Εννοείς ούτε τα classes που είναι generated με τα Entity Data Model default template (που κάνουν implement EntityObject) δεν έχουν γνώση για το πώς είναι stored / retieved?  Είχα την εντύπωση πως όταν τα objects κάνουν inherit από EntityObject, το κάνουν για να εκτελέσουν base methods του Entity Framework κλπ.

---

“Don’t worry if it doesn’t work right. If everything did, you’d be out of a job.”
(Mosher’s Law)