Έχει μήπως ακούσει κανείς για ένα project με το όνομα InterLinq; Επιτρέπει την δημιουργία linq statements τα οποία μπορούν να γραφτούν σε ένα client και να εκτελεστούν σε ένα server αφού περάσουν από ένα κανάλι WCF. Έχει extensions για να λειτουργεί σαν Linq to Objects/SQL/Entity Framework.

Το δοκιμάσαμε στην δουλειά και το αποτέλεσμα είναι εντυπωσιακό. Ουσιαστικά στον client γράφεις κανονικά linq και αυτό τρέχει στον server αφού φτάσει εκεί μέσω WCF σε ένα service που έχει μια service method.

Το ερώτημα είναι πόσο θα μπορούσε να βασιστεί κάποιος σε αυτό. Κυρίως επειδή το project περιέχει υλοποίηση των linq expressions από την αρχή, κυρίως για να είναι serializable. 

---

Dimitris Papadimitriou Software Development Professional

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

Αν δούλευες με datasets και απλή SQL, θα έφτιαχνες τα statements στον client για να τα εκτελέσεις στο server? Αυτό θα δημιουργούσε αρκετά προβλήματα:

• Μεγαλύτερη σύνδεση μεταξύ client/server καθώς ο client θα πρέπει να ξέρει τί αντικείμενα χρησιμοποεί ο server.
• Αναγκαστικά ο client και ο server θα πρέπει να έχουν τις ίδιες κλάσεις.
• Ανταλλαγή πολύ περισσότερων πληροφοριών μεταξύ client/server απ' ότι είναι απαραίτητο. Αντί π.χ. να πεις "Μετάφερε Χ Ευρώ από το λογαριασμό Α στον Β", θα πρέπει να στείλεις πίνακες και πεδία. Αυτό δημιουργεί δύο προβλήματα:
• αυξάνει το latency (καθώς τα μηχανήματα επικοινωνούν μέσω δικτύου) και
• Ο client επηρεάζεται από τις αλλαγές στις περιττές πληροφορίες
• Το API επικοινωνίας μεταξύ client/server γίνεται πιο δύσκολο, καθώς ο client αναγκάζεται να πει στον server όχι μόνο το τί αλλά και το πως να το κάνει. Έτσι όμως κάνεις δυσκολότερη τη χρήση αρκετών τεχνικών, όπως την ασύγχρονη εκτέλεση και το conflict resolution.

Γενικά δεν εντυπωσιάζομαι πολύ ούτε από το EntityBag του Entity Framework ούτε το InterLinq ακριβώς επειδή κάνουν κάτι το οποίο δεν βοηθάει στις περισσότερες εφαρμογές. Τα προβλήματα που ανέφερα παραπάνω είναι ουσιαστικά τα προβλήματα που έχει το RPC (είτε ως RPC είτε ως COM+, WCF, J2EE) σε σχέση με το messaging. Δεν είναι τυχαίο ότι το Messaging είναι ο προτιμώμενος τρόπος για client/server και web service εφαρμογές.

Από την άλλη, αν η εφαρμογή σου είναι απλή και δεν σε πειράζει να δεθούν client και server, δεν πειράζει να χρησιμοποιήσεις το InterLinq ή το EntityBag. Αν και προσωπικά θα προτιμούσα να δουλέψω απευθείας με το Entity Framework και το EntityBag παρά με το Linq to SQL και το InterLinq, καθώς το Linq-to-SQL έχει πολλούς εκνευριστικούς περιορισμούς και το EntityBag είναι ενσωματωμένο στο EF και όχι κάποιο ανεξάρτητο πρόσθετο.

---

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

Πολύ λεπτομερής τοποθέτηση Παναγιώτη, όπως πάντα!

Αντιλαμβάνομαι τα προβλήματα που αναφέρεις. Προφανώς δεν μπορεί κανείς να εκτελεί πολλά linq statements στον client και να δουλεύει σαν να είναι στον server. Φυσικά αυξάνει το latency και δένει περισσότερο τον client με τον server. Είναι όμως κάποια σημεία που ένας client πρέπει να το κάνει αυτό. Για να γίνουν συγκεκριμένες δουλειές και έχοντας πάντα υπόψη ότι είναι μακρυά από την πηγή των δεδομένων.

Το ερώτημά μου κυρίως είναι πως σας φαίνεται το γεγονός ότι το συγκεκριμένο project υλοποιεί από την αρχή όλα τα expressions (βλ. εικόνα). Θα βασιζόσασταν πάνω σε κάτι τέτοιο; Γιατί κατά τα άλλα η αρχιτεκτονική του είναι αρκετά απλή και όμορφη.

 

---

Dimitris Papadimitriou Software Development Professional

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

.. νομίζω ότι κι αν δεν χρησιμοποιούσες τη συγκεκριμένη βιβλιοθήκη, και αντ' αυτού χρησιμοποιούσες κάποιο "command" pattern σε server και client,  πάλι θα είχες υλοποιημένα τα commands απο την αρχή.

Στην καλύτερη των περιπτώσεων, ίσως πμορούσες δυναμικά να προσθέσεις assemblies τα οποία περιέχουν plugin-like command implementations. Αν κατάλαβα καλά, και η συγκεκριμένη υλοποίηση δεν θα απέκλειε κάτι τέτοιο. Οπότε ... no loss, no gain όσον αφορά αυτό - παντα αν έχω καταλάβει καλά τα προηγούμενα, ε;

Κατα τ' άλλα, γενικά δε μ' αρέσει η φιλοσοφία του utility αυτού. Κάνει expose στον client πράγματα τα οποία παραβιάζουν το traditional encapsulation και πιθανώς να είναι "φλύαρο" στο καλώδιο. Αλλά πάλι ίσως πεί κανείς ότι είμαι κολλημένος purist .

Άρα η ερώτηση είναι  ...  σε έχει βολέψει; Βρίσκεις  κάποια πράγματα στα οποία σου έχει λύσει τα χέρια σε σχέση με πιο παραδοσιακές μεθόδους; Έχεις βρεί κάποιο μειονέκτημα στη χρήση του, που να σε προβληματίζει όσον αφορά την χρήση στην παραγωγή; Αν όχι ... go for it. Η γραμμή μεταξύ innovation και over-engineering είναι πάντα θολή

---

Angel
O:]

Παναγιώτης Καναβός:

Αν και προσωπικά θα προτιμούσα να δουλέψω απευθείας με το Entity Framework και το EntityBag παρά με το Linq to SQL και το InterLinq, καθώς το Linq-to-SQL έχει πολλούς εκνευριστικούς περιορισμούς και το EntityBag είναι ενσωματωμένο στο EF και όχι κάποιο ανεξάρτητο πρόσθετο.

Ξαναδιάβαζα τη συζήτησή μας, γιατί βέβαια δεν έχω πάρει ακόμα τις αποφάσεις μου. Είναι δύσκολες αποφάσεις αυτές!

Πρόσεξα Παναγιώτη ότι είπες ότι το EntityBag είναι ενσωματωμένο στο EF. Δεν είναι ακριβώς ενσωματωμένο. Είναι ξεχωριστό project στο code.msdn.com και δεν γίνεται ακόμα ship με το EF. Ελπίζω να ενσωματωθεί κάποια στιγμή, αλλά σίγουρα δεν θα γίνει κάτι τέτοιο στην 1η release του EF. Με προβληματίζει βέβαια και το ότι η τελευταία release του entityBag έγινε τον Ιανουάριο και για 5 μήνες πλέον δεν υπάρχει τίποτα νεότερο.

---

Dimitris Papadimitriou Software Development Professional

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

Δεν βλέπεις κάτι νεότερο γιατί η ανάπτυξη του project έχει ολοκληρωθεί, όπως περιγράφει ο δημιουργός του στο EntityBag - Wrap Up and Future Directions. Όσον αφορά την επιλογή που έχεις να κάνεις, δεν νομίζω ότι έχει να κάνει μεταξύ InterLinq και EntityBag αλλά με το αν θα δέσεις τους client με το server. Τόσο το EntityBag όσο και το InterLinq απαιτούν ο client να γνωρίζει το object model του server και η επικοινωνία μεταξύ τους να περιοριστεί μόνο σε ό,τι μπορεί να εκφραστεί μέσω LINQ - δηλαδή data manipulation. Αυτό μπορεί να είναι χρήσιμο για να φτιαχτεί γρήγορα μία data entry εφαρμογή, είναι όμως πολύ περιοριστικό αν απαιτείται και λογική στην πλευρά του server.

Στη θέση σου πρώτα θα αποφάσιζα αν όντως θέλω να επικοινωνώ με object graphs. Δεν είναι τυχαίο ότι Web Services, J2EE, WCF και COM+ (βασικά όλες οι τεχνολογίες που χρησιμοποιούνται για application servers) δεν δίνουν σημασία στην επικοινωνία χρησιμοποιώντας object graphs. Αυτό απαιτεί δέσιμο μεταξύ client και server, απαιτεί πιο fat client, καταλήγει να μεταφέρει πολύ πληροφορία μέσω του δικτύου, κάνει δυσκολότερη τη χρήση transactions, queueing, ασύγχρονης εκτέλεσης και είναι δυσκολότερο να τροποποιηθεί.

---

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

Με μεγάλη σιγουριά το λες. Δεν μπορεί να έχει ολοκληρωθεί εφόσον δεν έχει ολοκληρωθεί το EF το ίδιο! Και το συγκεκριμένο post έχει γραφτεί 5 μήνες πριν. π.χ. αν κατεβάσεις αυτή τη στιγμή τις τελευταίες εκδόσεις και των δυο θα δεις ότι το EntityBag δεν γίνεται build, γιατί στην τελευταία beta του EF έχουν κάνει μια μικρή αλλαγή. Χαζή μεν και είναι μια γραμμή που αλλάζεις στο EntityBag και είναι όλα ok, αλλά είναι ένα παράδειγμα. Κατά τα άλλα το διάβασα το συγκεκριμένο blog και αν πρόσεξες έκανα κι ένα σχόλιο-ερώτηση από κάτω.

Κατά τα άλλα, προφανώς το InterLinq και το EntityBag δεν σχετίζονται μεταξύ τους. Το 1ο έχει να κάνει με quering και το 2ο δίνει μια λύση στο θέμα disconnected entities και change tracking. Έχει κάποια σχέση η 2η παράγραφός σου με κάποιο από τα δυο;

---

Dimitris Papadimitriou Software Development Professional

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

    Όσο κοιτάω το EntityBag τόσο αισθάνομαι ότι δημιουργήθηκε ως sample implementation και μπορεί να μην προχωρήσει. Με δεδομένο ότι ο δημιουργός του, ο Daniel Simmons δουλεύει στην ομάδα του EF, μπορεί να το παράτησε αυτός, να το παράτησε η ομάδα, ή απλά να περιμένουν να φτάσουν πιο κοντά στην τελική μορφή του VS 2008 SP1 πριν ασχοληθούν ξανά με το EntityBag. Εφόσον πάντως το έχει βγάλει με έκδοση 1.1 τουλάχιστον θεωρεί ότι έχει τελειώσει για την ώρα.

    Για τη δεύτερη ερώτηση, τα προβλήματα που περιγράφω έχουν να κάνουν και με τις δύο περιπτώσεις. Καταρχήν, το ισχυρό δέσιμο client/server ισχύει και στις δύο περιπτώσεις. Αν ζητήσω μέσω Interlinq από ένα service να μου δώσει το λογαριασμό ενός πελάτη θα πρέπει να έχω κάπου την κλάση του και στο server για να μπορέσω να το χρησιμοποιήσω. Αν αλλάξει κάτι στο server, θα έχω πρόβλημα και στον client. Για να μπορέσω να κάνω query θα πρέπει ο client να χρησιμοποιεί τα ίδια αντικείμενα με το server. 
    Αν, για παράδειγμα, ο client θέλει να μάθει την κατάσταση της παραγγελίας ενός πελάτη, θα πρέπει να έχει τα ίδια αντικείμενα (πελάτης, παραγγελία, ιστορικό της παραγγελίας κλπ) όπως ο server. Ο server όμως θα έχει και μεταφορικές εταιρείες, αναφορές από τις μεταφορικές, αποθέματα σε αποθήκες, πίνακες παρακολούθησης εγγράφων (αν κάποιες φάσεις της παραγγελίας περιλαμβάνουν και έντυπες φόρμες), πιθανώς και αλληλογραφία με το τελωνείο. Για να μπορέσει ο client να κάνει query για την κατάσταση θα πρέπει ή να έχει πρόσβαση σε όλα αυτά τα αντικείμενα, ή με κάποιο τρόπο το απλοποιημένο query του client να μετατραπεί στο αρκετά πιο πολύπλοκο query του server.
    Και μετά θα πρέπει να τα αλλάξεις όλα όταν ένας νόμος θα απαιτεί π.χ. και την έγκριση της υγειονομικής υπηρεσίας. Εϊναι προτιμότερο να φτιάξεις μία μέθοδο GetOrderStatus στο server για να κάνει όλη τη δουλειά κρύβοντας όλη τη φασαρία παρά να προσπαθείς να κάνεις το ίδιο στον client.

    Σχετικά με τα disconnected entities, το EntityBag δεν ασχολείται ακριβώς με αυτό το θέμα. Στα περισσότερα ORMs μία οντότητα θεωρείται disconnected από τη στιγμή που θα γίνει detach από το context που τη δημιούργησε, παρότι παραμένει στο ίδιο app domain. Το change tracking γίνεται σε αυτό το επίπεδο και αφορά είτε τις αλλαγές που γίνονται στα αντικείμενα όσο είναι ακόμα attached ή τις διαφορές που εντοπίζονται όταν γίνονται (re)attach σε ένα context.  To EntityBag λύνει το πρόβλημα του πως μεταφέρεις αλλαγές που έχουν εντοπιστεί σε ένα context σε κάποιο άλλο μέσω WCF - και όχι μόνο.
Και πάλι όμως δένεις client και server και τους βάζεις να επικοινωνήσουν ουσιαστικά μέσω object diffgrams. Αν για παράδειγμα, χρειαστεί να ακυρώσω μία παραγγελία, ο client θα πρέπει να φορτώσει όλα τα αντικείμενα που εμπλέκονται στην παραγγελία, να τα τροποποιήσει και να στείλει όλες τις αλλαγές πίσω (και στην υγειονομική υπηρεσία). Εναλλακτικά, θα μπορούσα να έχω μία μέθοδο ChangeOrderStatus και πίσω από αυτή να κρύψω όλη τη φασαρία.

    Σε τελική ανάλυση, το αν θα χρησιμοποιήσεις Interlinq, EntityBag ή service methods είναι θέμα encapsulation και ποιός έχει την ευθύνη για τα queries και τις αλλαγές: ο client ή το server component. Τα Interlinq και Entitybag έχουν χειρότερο encapsulation και μεταφέρουν την ευθύνη στον client. Τα service methods έχουν καλύτερο encapsulation και μεταφέρουν την ευθύνη στο server.

---

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

Παναγιώτης Καναβός:

    Όσο κοιτάω το EntityBag τόσο αισθάνομαι ότι δημιουργήθηκε ως sample implementation και μπορεί να μην προχωρήσει. Με δεδομένο ότι ο δημιουργός του, ο Daniel Simmons δουλεύει στην ομάδα του EF, μπορεί να το παράτησε αυτός, να το παράτησε η ομάδα, ή απλά να περιμένουν να φτάσουν πιο κοντά στην τελική μορφή του VS 2008 SP1 πριν ασχοληθούν ξανά με το EntityBag. Εφόσον πάντως το έχει βγάλει με έκδοση 1.1 τουλάχιστον θεωρεί ότι έχει τελειώσει για την ώρα.

Κάπως έτσι μου φαίνεται κι εμένα. Ας ελπίσουμε ότι θα υπάρξει συνέχεια.

Παναγιώτης Καναβός:

    Για τη δεύτερη ερώτηση, τα προβλήματα που περιγράφω έχουν να κάνουν και με τις δύο περιπτώσεις. Καταρχήν, το ισχυρό δέσιμο client/server ισχύει και στις δύο περιπτώσεις. Αν ζητήσω μέσω Interlinq από ένα service να μου δώσει το λογαριασμό ενός πελάτη θα πρέπει να έχω κάπου την κλάση του και στο server για να μπορέσω να το χρησιμοποιήσω. Αν αλλάξει κάτι στο server, θα έχω πρόβλημα και στον client. Για να μπορέσω να κάνω query θα πρέπει ο client να χρησιμοποιεί τα ίδια αντικείμενα με το server. 
    Αν, για παράδειγμα, ο client θέλει να μάθει την κατάσταση της παραγγελίας ενός πελάτη, θα πρέπει να έχει τα ίδια αντικείμενα (πελάτης, παραγγελία, ιστορικό της παραγγελίας κλπ) όπως ο server. Ο server όμως θα έχει και μεταφορικές εταιρείες, αναφορές από τις μεταφορικές, αποθέματα σε αποθήκες, πίνακες παρακολούθησης εγγράφων (αν κάποιες φάσεις της παραγγελίας περιλαμβάνουν και έντυπες φόρμες), πιθανώς και αλληλογραφία με το τελωνείο. Για να μπορέσει ο client να κάνει query για την κατάσταση θα πρέπει ή να έχει πρόσβαση σε όλα αυτά τα αντικείμενα, ή με κάποιο τρόπο το απλοποιημένο query του client να μετατραπεί στο αρκετά πιο πολύπλοκο query του server.
    Και μετά θα πρέπει να τα αλλάξεις όλα όταν ένας νόμος θα απαιτεί π.χ. και την έγκριση της υγειονομικής υπηρεσίας. Εϊναι προτιμότερο να φτιάξεις μία μέθοδο GetOrderStatus στο server για να κάνει όλη τη δουλειά κρύβοντας όλη τη φασαρία παρά να προσπαθείς να κάνεις το ίδιο στον client.

Δεν διαφωνώ καθόλου. Όντως στο συγκεκριμένο παράδειγμα η λύση είναι η υλοποιηθεί μια GetOrderStatus στο server. Δεν είναι δυνατόν ο client να κάνει ένα πολύπλοκο query με δικά του κριτήρια για να αποφασίσει για το status μιας παραγγελίας. Για όλους τους λόγους που ανέφερες. Δεν είναι όμως αυτό ο μόνος λόγος που θέλεις να κάνεις ένα query από τον client στον server. Εγώ σκεφτόμουν πολύ πιο απλά σενάριο. π.χ. φέρε μου τις παραγγελίες του τελευταίου μήνα. Ή τις παραγγελίες πάνω από 100EUR. Σε αυτή την περίπτωση δεν θα ήθελα να έχει ο server μου GetLastMonthOrders ή GetOrdersAboveAmount(int amount). Θα ήθελα να περνάω ένα ελεύθερο query. π.χ. GetOrders(object query). Και για να είμαι και type safe και cool με linq και άλλα τέτοια θα ήθελα να μπορώ να περάσω ένα linq query στον server αντί για ένα custom made (από μένα) query object (όπως έκανα στο παρελθόν). Αυτό δίνει το interlinq.

Παναγιώτης Καναβός:

    Σχετικά με τα disconnected entities, το EntityBag δεν ασχολείται ακριβώς με αυτό το θέμα. Στα περισσότερα ORMs μία οντότητα θεωρείται disconnected από τη στιγμή που θα γίνει detach από το context που τη δημιούργησε, παρότι παραμένει στο ίδιο app domain. Το change tracking γίνεται σε αυτό το επίπεδο και αφορά είτε τις αλλαγές που γίνονται στα αντικείμενα όσο είναι ακόμα attached ή τις διαφορές που εντοπίζονται όταν γίνονται (re)attach σε ένα context.  To EntityBag λύνει το πρόβλημα του πως μεταφέρεις αλλαγές που έχουν εντοπιστεί σε ένα context σε κάποιο άλλο μέσω WCF - και όχι μόνο.
Και πάλι όμως δένεις client και server και τους βάζεις να επικοινωνήσουν ουσιαστικά μέσω object diffgrams. Αν για παράδειγμα, χρειαστεί να ακυρώσω μία παραγγελία, ο client θα πρέπει να φορτώσει όλα τα αντικείμενα που εμπλέκονται στην παραγγελία, να τα τροποποιήσει και να στείλει όλες τις αλλαγές πίσω (και στην υγειονομική υπηρεσία). Εναλλακτικά, θα μπορούσα να έχω μία μέθοδο ChangeOrderStatus και πίσω από αυτή να κρύψω όλη τη φασαρία.

Τώρα μπήκα λίγο στον κώδικά του και είδα τι κάνει. Όντως παίρνει ένα snapshot του context (για την ακρίβεια του ObjectStateManager του). Με απογοήτευσε! Δεν "με" αρέσει! Σχετικά με το παράδειγμά σου όμως, πάντα υπάρχει η περίπτωση να θέλεις να αλλάξεις ένα entity property μόνο και να χρειάζεται να φορτώσεις ένα ολόκληρο entity με related entities. Δεν θα έχεις Changed<Entity><Property> μεθόδους για τα πάντα! Το ερώτημα είναι στην πολιτική που θέλεις να έχεις στην αποθήκευση (φυσικά μπορεί να έχεις και τις δυο σε διάφορα σημεία του συστήματος)

1. Αν σε ενδιαφέρει απλά το client wins (αλλαγές που έγιναν από άλλους χρήστες όσο ο χρήστης μας δούλευε με τα data θα χαθούν) τότε δεν χρειάζεσαι diffgrams.
2. Αν σε ενδιαφέρει το server wins (αν έγιναν αλλαγές από άλλους χρήστες να ακυρωθεί το update) τότε χρειάζεσαι diffgrams για να ελέγξεις σε τι κατάσταση ήταν τα data του χρήστη όταν τα πήρε σε σχέση με την ώρα που θέλει να τα αποθηκεύσει. Φυσικά υπάρχει διάφορα σενάριο εδώ που σχετίζονται και με child records.
   

---

Dimitris Papadimitriou Software Development Professional

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

Και η απάντηση ήρθε από τον ίδιο τον δημιουργό μετά από ερώτημά μου:

Danny Simmons:

To be completely honest, I just haven't had time to work on EntityBag for quite a while.  I'm trying to get cycles (or find someone else on the team who has cycles) to update it for sp1 beta, but so far that just hasn't happened.

I still point people here as a resource for thinking through the problems and learning more of the details about the framework, but this was never intended to be a production component like what we ship with the EF directly.  Sadly, the fact that we don't have something more like this is a definite lack in v1 of the EF which we're working to address with a real, supported component in v2.

---

Dimitris Papadimitriou Software Development Professional

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

    Όσον αφορά το querying, το reporting και τα ad-hoc queries είναι ίσως η μόνη περίπτωση όπου έχει νόημα να φτιάξεις ένα query στον client και να το εκτελέσεις στον server, με την προϋπόθεση ότι τα αντικείμενα στα οποία κάνεις το query έχουν φτιαχτεί γι αυτό το λόγο και δεν είναι τα γενικά αντικείμενα του server, π.χ. προέρχονται από ένα business object model ειδικά για reporting, ή από το UDM που χρησιμοποιούν τα Reporting Services και ο OLAP. Αυτό σημαίνει είτε ότι θα πρέπει να χρησιμοποιείς διαφορετικό data context από αυτό που χρησιμοποιεί κανονικά ο server και θα χτυπάς απευθείας τη βάση, ή ότι θα χρησιμοποιείς ένα custom LINQ provider ο οποίος θα μεταφράζει τα queries σε κάτι άλλο.
    Αυτή ακριβώς είναι και η ιδέα πίσω από το UDM, να παρέχει ένα μοντέλο των δεδομένων προσπαρμοσμένο στις ανάγκες του reporting και του ad-hoc querying. Ένα τέτοιο μοντέλο αλλάζει σχετικά σπάνια και κρύβει τις συχνές αλλαγές στη βάση, οπότε διευκολύνεται πολύ το reporting. Έψαξα πάντως αλλά δεν βρήκα ακόμα κάποιο έτοιμο Linq to UDM.

    Για τα entities, αυτά που λες προϋποθέτουν ότι το business logic των αντικειμένων σου ζεί στον client, είτε μαζί με τα αντικείμενα, είτε με αντικείμενα τα οποία είναι μονίμως σηκωμένα στον server (όπως γινόταν με το Remoting και το Java RMI). Είναι πολύ σπάνιο ένας client να θέλει να αλλάξει ένα property "έτσι". Συνήθως η αλλαγή γίνεται στα πλαίσια ενός use case ή business process. Αυτό το business logic είναι προτιμότερο να ζει στον server παρά στον client. Έτσι και μεταφέρεις τη λογική στο server έχεις πολλές επιλογες:

• μπορείς να φτιάξεις μία μέθοδο για κάθε business use case η οποία θα σηκώνει τα κατάλληλα αντικείμενα και θα κάνει όλη την απαραίτητη επεξεργασία στα πλαίσια ενός transaction
• μπορείς να φτιάξεις μία μόνο μέθοδο η οποία θα δέχεται ως πρώτη παράμετρο το business functionality που πρέπει να εκτελέσει. Έτσι προστατεύεις τον client από αλλαγές στο server.
• και το επόμενο βήμα, μπορείς να φτιάξεις ένα διαφορετικό μήνυμα για κάθε business function και να ανταλλάσεις μόνο μηνύματα μεταξύ server και client. Αυτή είναι και η πιο scalable λύση.
      Αντί π.χ. να φορτώσεις τον πελάτη για να αλλάξεις τη διεύθυνση του ή κάποιο άλλο προσωπικό στοιχείο, καλείς μία μέθοδο "UpdateCustomerRecord" στην οποία στέλνεις τις αλλαγές που θέλεις να γίνουν.  Ή φτιάχνεις ένα μήνυμα "CustomerRecordChange" με τα δεδομένα αυτά.

Μπορεί έτσι να φαίνεται ότι χάνεις το type safety, αλλά στην περίπτωση επικοινωνίας μεταξύ client/server το type safety δημιουργεί πολλά προβλήματα. Το type safety δημιουργεί ισχυρή σύνδεση μεταξύ client και server, ακριβώς σε ένα περιβάλλον στο οποίο θέλεις το αντίθετο. Κάθε φορά που αλλάζει αυτή η μορφή, θα πρέπει να ξανακάνεις build το server, τους clients και να τους ξανακάνεις deploy.

    Όσον αφορά το concurrency και το versioning (γιατί αυτό περιγράφεις, όχι τον τρόπο αποθήκευσης), δεν παίζει και τόσο μεγάλο ρόλο στην επικοινωνία client/server. Είναι κάτι το οποίο αφορά (ή θα πρέπει να αφορά) το server και μόνο. Από τη στιγμή που δεν προσπαθεί κανείς να σώσει τα αντικείμενα του client στο server "όπως είναι" δεν υπάρχει λόγος να περιοριστεί στο pessimistic/optimistic μοντέλο του ADO και του ADO.NET. Εξάλλου, όταν δουλεύει κανείς με περίπλοκα αντικείμενα το μοντέλο αυτό δεν δουλεύει καλά, καθώς πρέπει πλέον να ελέγχεις ολόκληρα object graphs, όχι μεμονωμένα αντικείμενα.
    Μάλιστα, κάθε business function απαιτεί διαφορετική αντιμετώπιση. Μπορει κανείς να δομήσει τα business functions έτσι ώστε να μην υπάρχει πρόβλημα αν ένα αντικείμενο έχει τροποποιηθεί από άλλο client. Μία μεταφορά χρημάτων από ένα λογαριασμό σε άλλο δεν υπάρχει λόγος να εμποδίσει μία ανάληψη από κάποιο από τους δύο λογαριασμούς. Επίσης, η προσθήκη μίας νέας παραγγελίας δεν πρέπει να εμποδίζεται από την αλλαγή διεύθυνσης του πελάτη. Ακόμα και αν γίνουν ταυτόχρονα μία αλλαγή διεύθυνσης και μία αλλαγή ονόματος για τον ίδιο πελάτη, δεν υπάρχει λόγος η μία αλλαγή να εμποδίσει την άλλη. Ακόμα και αν το ένα function πρέπει να τρέξει κώδικα που επηρεάζεται από τις αλλαγές του δεύτερου, μπορεί να το δει (με optimistic concurrency), να ξαναφορτώσει τα δεδομένα και να ξαναπροσπαθήσει να κάνει τις αλλαγές που θέλει, χωρίς ποτέ να το καταλάβει ο client.
    Τέλος, στην περίπτωση που δύο διαφορετικοί clients δουλεύουν με την ίδια παραγγελία, μπορείς να προσθέσεις ένα μηχανισμό checkin/checkout έτσι ώστε μόνο ένας να μπορεί να κάνει editing σε ολόκληρη την παραγγελία (και τα item της), ενώ οι άλλοι να μπορούν να τη δουν μόνο. 

---

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

Πάντως, όπως βλέπουμε υπάρχει ανάγκη για partially connected applications όπου ο client διατηρεί τοπικά μια μικρότερη έκδοση του κύριου data-store ώστε να κάνεi persist τα data μεταξύ των sessions, μέχρι να μπορέσει να τα στείλει , κλπ, κλπ, οπότε μοιραία χρειάζεται να υπάρχει ένα client-side object model και ένα server-side με αντίστοιχους μηχανισμούς για μετατροπή των δεδομένων ανάλογα πριν περάσουν από τον client στον server και το ανάποδο, όπου τελικά ουσιαστικά γίνεται ανταλλαγή DTOs.

---

Vir prudens non contra ventum mingit

Σχετικά με το querying, όντως θα ήταν πολύ ωραίο αυτά τα queries να τρέχουν σε άλλο μοντέλο-context.

Για τα entities, λέω ακριβώς το αντίθετο και είναι πολύ κοντά σε αυτό που λες κι εσύ. Δεν απαιτεί κανένα business logic στον client. Ούτε καν type safety το οποίο όπως λες κι εσύ δένει ισχυρά client/server. Δεν μιλάω καν για CustomerRecordChange message, αλλά για EntityRecordChange message. Αυτό όμως δεν σημαίνει δεν θα έχεις όμως και σημεία σε ένα client που αναγκαστικά θα είναι δεμένα με τον server.

Με το concurrency (αυτό εννοώ client wins/server wins), είναι σημεία που όντως ο μηχανισμός check in/out θα ήταν χρήσιμος. Είναι όμως πολύ συγκεκριμένα και σπάνια σημεία και θα το αποφύγω προς το παρόν στον σχεδιασμό μου. Σε αυτά τα σπάνια σημεία θα χρησιμοποιήσω τον κλασσικό μηχανισμό pessimistic/optimistic όπως ήταν και στο ADO.NET. Το EF τον υποστηρίζει σχετικά καλά, έστω κι αν θέλει λίγο κώδικα. Δεν θα πάει χαμένος.

---

Dimitris Papadimitriou Software Development Professional

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