Θα ήθελα να ξεκινήσω ένα θέμα συζήτησης σχετικά με τη σχεδίαση n-tier εφαρμογών (το οποίο όμως να μην αφορά αποκλειστικά enterprise εφαρμογές, ούτε να πραγματεύεται μόνο serviced components).

Γενικότερα σε 3-tier περιβάλλον όλοι ξέρουμε το τρίπτυχο presentation-middle-DAL. Για να καλύψω λίγο το DAL, να αναφέρω οτι σε αρκετές περιπτώσεις χρησιμοποιώ το MS DAAB (Data Access Application Block) ενώ σε κάποιες από αυτές έχω φτιάξει ακόμα ένα layer από πάνω του (adapter θα μπορούσε να το ονομάσει κανείς) για να διευκολυνομαι με transactions και λοιπες λεπτομέρειες.

Σχετικά με το persistence, με απασχολεί ο τρόπος ορισμού των business objects και το πώς αυτά τελικά επικοινωνούν με το DAL. Μια πρακτική που εφάρμοσα παλιότερα, η οποία είναι λειτουργική σε κάποιες περιπτώσεις, είναι ο ορισμός ορισμένων data carrier objects τα οποία "σερβίρονται" σε αντίστοιχους persistence managers (εναν για κάθε data carrier class ή έναν για κάθε ομάδα σχετικών types - οχι απαραίτητα derived από το ίδιο class) οι οποίοι εκτελούν τις βασικές retrieval-persistence εργασίες.

Ητοι: Δημιουργείς ένα data carrier object (οχι απαραίτητα "χαζό", μπορεί να αναπαριστά ίσως και πλήρως κάποιο domain entity) με awareness για το αν έχει γίνει load, save κλπ. Παντα περνάς αυτό στον "persistence manager", και αυτός αποφασίζει πώς και τι θα του φορτώσει. Το ίδιο και με την αποθήκευση ή το update. Αρα ο "persistence manager" εκτελεί τις βασικές CRUD διαδικασίες, ενώ το instantiation των objects μπορεί να επιτευχθεί είτε από τον caller, είτε από τον "manager" είτε μέσω κάποιου factory, αναλογως την περίπτωση. Ο "manager" πιθανόν να διαθέτει διάφορες shared μεθόδους επίσης, με τις οποίες επιστρέφει resultsets είτε με τη μορφή collections από data carrier objects, είτε χρησιμοποιώντας καταραμένα datasets, datatables και όλα τα λοιπά αντικείμενα του διαβόλου

Αλλη προσέγγιση είναι το ίδιο το αντικείμενο να εκτελεί τις βασικές CRUD λειτουργίες του. (Πως το έλεγε ο Fowler αυτο; Domain Data Object ; ) Εδώ έχεις σημαντικά ωφέλη αλλά ίσως και σημαντικό βαθμό coupling και code duplication σε κάποιες περιπτώσεις. Ισχύει το ίδιο για τις shared methods, ή μπορεί να φεύγουν σε κάποια άλλα classes, αναλόγως με τη σχεδίαση.

Σταματώ εδώ, γιατί δεν είναι σκοπός μου να αναπτύξω όλες τις σχεδιάσεις που μου έχουν κατέβει. Εχω απλώς την περιέργεια: Σε πρακτικό (και όχι θεωρητικό επίπεδο - μην μου φερετε ολο το Fowler στο κεφάλι!) πως μοντελοποιείτε εσείς τα παραπάνω, και ποιές πρακτικές σας φάνηκαν πιό αποδοτικές; Θα ήταν πιστεύω ενδιαφέρουσα μια τέτοια συζήτηση.

---

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

DotSee Web Services

Έτσι για να έχω μια πιο γενική ιδέα. Τι θα εξυπηρετεί μια εφαρμογή που θα έχει persistnce στα data; Για να είναι ταχύτερη; Cashing δηλαδή; Τι είδους εφαρμογή έχεις στο μυαλό σου που θα χρειαζόταν κάτι τέτοιο;

G.J.

---

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

Δεν έχω συγκεκριμένη εφαρμογή στο μυαλό μου, γι'αυτό δεν είπα και πάρα πολλά. Ηθελα περισσότερο να το συζητήσω σε επίπεδο σχεδίασης. Γενικά η δημιουργία persistence layer υπάρχει (έμμεσα) σε όλες τις n-tier εφαρμογές, υπό την έννοια οτι τελικά κάπου πρέπει να τα χώνεις τα αναθεματισμένα τα data! Σε βάση, σε text files, σε xml, καπου! Δεν εννοώ το persistence με την έννοια του serialization ή του caching, αλλά με την έννοια του data store γενικότερα. Κάποιος μηχανισμός είναι αυτός που τελικά αποθηκεύει και ανακτά τα δεδομένα, π.χ., σε ένα RDBMS. Αυτό το μηχανισμό και τις πιθανές υλοποιήσεις του θέλω να συζητήσω.

Φυσικά, η πιό απλή μορφή του μηχανισμού είναι αυτή που υπάρχει σε μια βασική client/server εφαρμογή...insert, update κλπ από τον rich client απευθείας στη βάση. Σε n-tier όμως δεν είναι (η δεν θα έπρεπε να είναι) έτσι, και θα πρέπει να υπάρχει ένα μεγαλύτερο επίπεδο αφαίρεσης.

---

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

DotSee Web Services

Γιατί όχι η χρήση κάποιου έτοιμου objects persistence library. Εγω θα πρότεινα το NHibernate (port του Java Hibernate), αν και σε beta έκδοση το χρησιμοποιούν ήδη σε πολλά project, είναι free και το σημαντικότερο έχει πολύ μεγάλο activity στο sourceforge.net που σημαίνει ότι έχει μέλλον. Στο κόσμο της Java είναι ήδη best seller.

N.K.

---

Nikos Κ.
ALT.NET

kyriakoy wrote:

Γιατί όχι η χρήση κάποιου έτοιμου objects persistence library. Εγω θα πρότεινα το NHibernate (port του Java Hibernate), αν και σε beta έκδοση το χρησιμοποιούν ήδη σε πολλά project, είναι free και το σημαντικότερο έχει πολύ μεγάλο activity στο sourceforge.net που σημαίνει ότι έχει μέλλον. Στο κόσμο της Java είναι ήδη best seller. N.K.

Εκανα ήδη μια ερώτηση για το αν κάποιος έχει χρησιμοποιήσει το Lattice (http://www.dotnetzone.gr/forums/ShowPost.aspx?PostID=925). Ναι, η χρήση object persistence lib είναι μια επιλογή, αλλά δεν ήθελα να το πάω τόσο μακριά. Εκεί έχεις πράγματα που λειτουργούν όπως κάποιοι αποφάσισαν, έχεις mappings, έχεις πιθανά bugs ή functionality που θα ήθελες και δεν έχουν υλοποιήσει....και γενικά έχεις πολλά περισσότερα από ο,τι θα μπορούσες να αξιοποιήσεις.

Δεν πιστεύω οτι ο καθένας που ξεκινά να φτιάξει μια εφαρμογή χρησιμοποιεί και ένα έτοιμο persistence library. Συνήθως δημιουργεί το δικό του, βασικό persistence framework (ακόμα και αν αυτό μεταφράζεται στο να εκτελούν τα ίδια τα objects τα CRUD operations τους). Εκεί ήθελα περισσότερο να εστιάσω: Τι κάνουν οι συνάδελφοι σε αυτές τις περιπτώσεις, τι patterns προτιμούν να υλοποιούν ή να μιμούνται.

---

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

DotSee Web Services

kyriakoy wrote:

Γιατί όχι η χρήση κάποιου έτοιμου objects persistence library. Εγω θα πρότεινα το NHibernate (port του Java Hibernate), αν και σε beta έκδοση το χρησιμοποιούν ήδη σε πολλά project, είναι free και το σημαντικότερο έχει πολύ μεγάλο activity στο sourceforge.net που σημαίνει ότι έχει μέλλον. Στο κόσμο της Java είναι ήδη best seller.

Ετσι που το θέτεις ουσιαστικά μας παραπέμπεις σε ένα O/R Tool. Δεν το ξέρω το εργαλείο, αλλά δεν πιστεύω σε ports όσο αφορά το Bussiness Layer. Κάτι που είναι σχεδιασμένο σε Java δεν έχει λάβει εξ ορισμού τα Bussiness Στοιχεία που περιλαμβάνει το λειτουργικό των Windows, component services, transaction coorinator, και λογικά δεν κανει χρήση αυτών.

Στην πραγματικότητα αυτό που έκανε το MDAC (Microsoft Data Access Components - ADO/DAO/OLEDB/ADOX/RDO) ανάμεσα στους προγραμματιστές κάτω από την πλατφόρμα των Windows τόσο δημοφιλής ήταν ακριβώς η χρήση αυτών των στοιχείων των Windows.

Αν αποκλείεις αυτά θέλοντας να φτιάξεις κώδικα backend που θα τρέχει παντού, κάτι παει και έρχεται, αλλά γιατί να χρησιμοποιήσεις Windows τότε; Εχει πραγματικά νόημα; Αξίζει το κόστος;

G.J.

---

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

Συμφωνώ και γενικότερα για τα ports από Java αλλά το συγκεκριμένο δείχνει ότι μάλλον είναι καλό port. Σε σχέση με την χρήση ή όχι O/R Mapper είναι γνωστό ότι υπάρχει μια ατελείωτη κουβέντα στο δίκτυο για το αν είναι αναγκαία, πιο εργαλείο είναι καλύτερο κλπ. Εγώ νομίζω πως υπάρχουν περιπτώσεις που μπορεί να χρησιμοποιηθεί αποδοτικά και στο .NET. Ειδικά αν έχει και extra «καλούδια» που σου ταιριάζουν όπως είναι το query language για objects και άλλα τα οποία δεν χρειάζεται να καθόμαστε να τα φτιάξουμε αφού υπάρχουν έτοιμα.

Άλλωστε και η Microsoft ετοιμάζει εδώ και καιρό το δικό της το ObjectSpaces.

N.K

---

Nikos Κ.
ALT.NET

Να πω μερικά πράγματα και ταυτόχρονα να γυρίσω σε αυτό που ξεκίνησε το thread.

Ναι ωραία είναι τα καλούδια, αλλά δεν έχεις δει ποτέ κάτι σαν αυτό; Δεν έχεις φτιάξει/χρησιμοποιήσει έτοιμο τέτοιο κώδικα;

Ενδεδειγμένος τρόπος για να τα κάνει κάποιος ένα τέτοιο data persistence data object δεν νομίζω ότι υπάρχει. Το implementation ενός ActiveX DLL που έχει data-binding behavior, simple bound ή complex bound, είναι ένας από τους πιθανούς τρόπους. Μπορεί να χρησιμοποιηθεί σαν αληθινό source ένα adodb recordset που έχει γίνει instance με WithEvents, και μπορεί να συνδεθεί σε μια OLEDB συμβατή datasource, ή ένα comma delimited αρχείο/xml αρχείο. Μπορείς να γράψεις ότι είδους κώδικα θέλεις μπροστά από τα method του αληθινού source μέσα στο "wrapper" datasource που φτιάχνεις.

Άλλος τρόπος είναι να γίνει implementation του OLE DB Simple Provider. Είναι πολύ πιο καλός τρόπος για το implementation ενός persistence data component όταν η πηγή είναι ένα αρχείο csv/xml ή τέλος πάντως κάτι πολύ μακριά από το να μπορεί να γίνει datasource από μόνο του.

Και τα δύο δεν είναι καινούργιοι τρόποι, ή ριζοσπαστικοί, κάτι που δεν έχει γίνει πριν. Έχουν και οι δύο δυνατότητα εγγενείς υποστήριξης των component services και του transaction coordinator που ολοκληρώνει κάθε λύση κάτω από το λειτουργικό των Microsoft Windows.

---

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

gcapnias wrote:

Να πω μερικά πράγματα και ταυτόχρονα να γυρίσω σε αυτό που ξεκίνησε το thread. Ναι ωραία είναι τα καλούδια, αλλά δεν έχεις δει ποτέ κάτι σαν αυτό; Δεν έχεις φτιάξει/χρησιμοποιήσει έτοιμο τέτοιο κώδικα;

Εχμ...με παραπέμπεις σε δικό μου άρθρο;

gcapnias wrote:

Ενδεδειγμένος τρόπος για να τα κάνει κάποιος ένα τέτοιο data persistence data object δεν νομίζω ότι υπάρχει.

Εδώ θα διαφωνήσω. Ενδεδειγμένοι τρόποι υπάρχουν πολλοί. Τουλάχιστον, μιλώντας για τον Fowler στο αρχικό μου post, έχω υπόψη μου το βιβλίο του "Patterns of Enterprise Application Architecture" το οποίο αναφέρει διάφορα patterns (σε θεωρητικό αλλά και πρακτικό επίπεδο) που μπορούν να υλοποιηθούν για τους εν λόγω σκοπούς. Ακόμα και τα frameworks που ασχολούνται με το θέμα και κυκλοφορούν στο εμπόριο, ακολουθούν ένα ή περισσότερα από αυτά τα patterns.

(Μην σας κάνω τον έξυπνο, δεν έχω διαβάσει όλο το Fowler, αλλά όσα είδα μου ήταν αρκετά για να σχηματίσω τις ερωτήσεις αυτές).

Κατά τα άλλα, όλα όσα λες είναι σωστά. Δεν μιλούσα όμως για raw code και πόσο μάλλον για recordsets και activeX DLLs. Μιλούσα για domain entities και τον τρόπο υλοποίησης του persistence τους ΧΩΡΙΣ τη χρήση έτοιμου framework. Για παράδειγμα, μοντελοποιείς ένα κάτι τι που λέγεται "Customer". Ε, μπορεί να κάνεις αυτό το Customer να κάνει load, save και update τον εαυτό του. Μπορεί επίσης να κάνεις αυτό το Customer να είναι "χαζό" και κάποιος άλλος (π.χ. CustomerManager) να αναλαμβάνει τις λειτουργίες αυτές. Μπορείς επίσης να μην θεωρείς το Customer ως ένα row ενός πίνακα ή join πινάκων σε επίπεδο βασης, αλλά να το φτιάξεις να παίζει το ρόλο iterator (με forward, rewind κλπ) - κατι που νομίζω οτι κάνει το MyGeneration - και να "παίξεις" με το ποιός αναλαμβάνει το persistence ανάλογα με το πλήθος των εγγραφών του.  Η, μπορεί να μην μοντελοποιήσεις καθόλου την έννοια Customer και για σένα να είναι ένα xml stream, ένα datarow, dataset ή οτιδήποτε άλλο έτοιμο μπορείς να χρησιμοποίήσεις από το υπάρχον σετ πραγμάτων που είναι διαθέσιμα, εκ των οποίων κάποια έχουν έτοιμους μηχανισμούς persistence. Ολες αυτές είναι επιλογές. Και όλες έχουν ωφέλειες και κόστη.

Προσωπικά είμαι υπερ των persistence manager classes με τον ένα ή τον άλλο τρόπο.

---

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

DotSee Web Services

cap wrote:

Εχμ...με παραπέμπεις σε δικό μου άρθρο;

Κουτέ, δεν είχα δικό σου post ακριβώς από πάνω μου! Αλλο post ήταν, και προσπαθησα να συνεχίσω από κει!

cap wrote:

(Μην σας κάνω τον έξυπνο, δεν έχω διαβάσει όλο το Fowler, αλλά όσα είδα μου ήταν αρκετά για να σχηματίσω τις ερωτήσεις αυτές).

Μάλιστα, αυτό σε αγχώνει; Μόνο αυτό από τα βιβλία του διάβασες;  Το θρύλο "Analysis Patterns : Reusable Object Models (Addison-Wesley Object Technology: Addison-Wesley Object Technology Series)" δεν το έχεις διαβάσει; Σίγουρα ο άνθρωπος είναι ένας θρύλος των καιρών μας και της επιστήμης. Το site του το έχεις δει;  Εχω αρχίσει να πιστεύω ότι υπάρχει άθρωπος που ασχολείται με software architeching και δεν τον έχει διαβάσει! Μήπως το έχεις διαβάσει πρόσφατα; Γιατί αυτό το άγχος; Πρέπει όλους να τους πίανει αυτό το άγχος γιατί και μένα με είχε πιάσει!

gcapnias wrote:

Ενδεδειγμένος τρόπος για να τα κάνει κάποιος ένα τέτοιο data persistence data object δεν νομίζω ότι υπάρχει.

cap wrote:

Εδώ θα διαφωνήσω. Ενδεδειγμένοι τρόποι υπάρχουν πολλοί. Τουλάχιστον, μιλώντας για τον Fowler στο αρχικό μου post, έχω υπόψη μου το βιβλίο του "Patterns of Enterprise Application Architecture" το οποίο αναφέρει διάφορα patterns (σε θεωρητικό αλλά και πρακτικό επίπεδο) που μπορούν να υλοποιηθούν για τους εν λόγω σκοπούς. Ακόμα και τα frameworks που ασχολούνται με το θέμα και κυκλοφορούν στο εμπόριο, ακολουθούν ένα ή περισσότερα από αυτά τα patterns.

Η διαφωνία που είναι; "Δεν υπάρχει ενδεδειγμένος τρόπος" από την μία, "Ενδεδειγμένοι τρόποι υπάρχουν πολλοί" από την άλλη. Ακόμα και κατά Martin Fowler υπάρχουν πολλοί τρόποι, περισσότεροι από ένας!

cap wrote:

Κατά τα άλλα, όλα όσα λες είναι σωστά. Δεν μιλούσα όμως για raw code και πόσο μάλλον για recordsets και activeX DLLs. Μιλούσα για domain entities και τον τρόπο υλοποίησης του persistence τους ΧΩΡΙΣ τη χρήση έτοιμου framework. Για παράδειγμα, μοντελοποιείς ένα κάτι τι που λέγεται "Customer". Ε, μπορεί να κάνεις αυτό το Customer να κάνει load, save και update τον εαυτό του. Μπορεί επίσης να κάνεις αυτό το Customer να είναι "χαζό" και κάποιος άλλος (π.χ. CustomerManager) να αναλαμβάνει τις λειτουργίες αυτές. Μπορείς επίσης να μην θεωρείς το Customer ως ένα row ενός πίνακα ή join πινάκων σε επίπεδο βασης, αλλά να το φτιάξεις να παίζει το ρόλο iterator (με forward, rewind κλπ) - κατι που νομίζω οτι κάνει το MyGeneration - και να "παίξεις" με το ποιός αναλαμβάνει το persistence ανάλογα με το πλήθος των εγγραφών του.  Η, μπορεί να μην μοντελοποιήσεις καθόλου την έννοια Customer και για σένα να είναι ένα xml stream, ένα datarow, dataset ή οτιδήποτε άλλο έτοιμο μπορείς να χρησιμοποίήσεις από το υπάρχον σετ πραγμάτων που είναι διαθέσιμα, εκ των οποίων κάποια έχουν έτοιμους μηχανισμούς persistence. Ολες αυτές είναι επιλογές. Και όλες έχουν ωφέλειες και κόστη.

Μην το παίρνεις έτσι. Ο κώδικας είναι το προιόν όλου του λογικού σχεδιασμού. Ολα αυτά που ζητάς, η μοντελοποίηση, υπάρχουν μέχρι ένα βαθμό και μέσα σε ένα απλό recordset. Την εποχή όμως που σχεδιαστηκε το recordset δεν είχαν εμπεδωθεί θεωρείες σαν αυτή του Fowler. Πόσο όμως, αυτά που λες, ανταποκρίνονται στο Dataset; Πόσο θα ανταπροκρίνονται στο ObjectSpace; Οι βαθμοί επαλήθευσης έχουν γίνει τεράστιοι!

---

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

Ωχ, ο χείμαρρος άνοιξε

Αν σου πω οτι δεν το εχω διαβάσει (ακόμα) θα φαω πολύ ξύλο; Σχετικά με το architecture μπορώ να χαρακτηρίσω τον εαυτό μου newbie (γι'αυτό και οι ερωτήσεις και το ανοιγμα του topic). Παντως οχι μόνο το γνωρίζω, το έχω πρόχειρο και μπροστά μου και είναι ο επόμενος στόχος μου. Το site δεν το έχω δει, αλλά αυτό θα ισχύει μέχρι σήμερα

Οσον αφορά στη διαφωνια, εγώ θεωρησα οτι με το να λες "ενδεδειγμένος τρόπος δεν υπάρχει" οτι γενικά το πεδίο είναι ασαφές και χαλαρό και δεν ορίζονται συγκεκριμένοι τρόποι. Από την άλλη μεριά, εγώ επεσήμανα οτι έχω πέσει σε παραπάνω από έναν ενδεδειγμένους (συγκεκριμένους) τρόπους υλοποίησης. Misunderstanding δικό μου.

Το οτι η μοντελοποίηση έχει επιτευχθεί σε μεγάλο βαθμό εντός των ίδιων των components του .NET, είναι ορθό. Ναι, οκ, μπορεις να θεωρήσεις οτι χρησιμοποιώντας ένα recordset/dataset/κατι επιτυγχάνεις κατά μεγάλο βαθμό έναν από τους ενδεδειγμένους τρόπους μοντελοποίησης. Απλά οι ερωτήσεις μου αφορούσαν την κατάσταση κατά την οποία τα layers είναι απολύτως διακριτά και υπάρχει μεγάλος βαθμός decoupling μεταξύ data access και business layer.

Τελικά όμως δεν πήρα απάντηση στην αρχική ερώτηση. Εχει κανείς patternάρει την υλοποίηση business objects και την επικοινωνία τους με το data access layer και έχει κάτι να μας προτείνει / υποδείξει σε πρακτικό επιπεδο; Ποιές είναι οι πιό σύνηθεις πρακτικές στην πρακτική, (Ελληνική ! με ο,τι συνεπάγεται αυτό) πραγματικότητα;

---

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

DotSee Web Services