Ανοίγω εδώ ένα θέμα το οποίο μπορεί άνετα να καταλήξει και στο Wiki ή να αποτελέσει πηγή για την δημιουργία ενός ωραίου άρθρου. Ξερω οτι μας βασανίζει (πολλούς από εμάς), αλλά δεν το είχαμε "πιάσει" ως τώρα στα χέρια μας αναλυτικά. Ιδού λοιπον:

Σενάριο: Θέλουμε να δημιουργήσουμε μια απλή εφαρμογή 3/n-tier (ας το περιορίσουμε σε windows forms για να μην μπερδευτούμε). Εχουμε στα χέρια μας την εξής απόφαση / περιορισμό αρχιτεκτονικής: Ομορφα objects στο middle tier ΧΩΡΙΣ να μιλάμε με datasets απευθείας στο presentation, και ένα DAL το οποίο μπορεί να είναι custom ή να αποτελείται από typed datasets/tableadapters ή απο οτιδήποτε άλλο θέλουμε.

Πιθανές προσεγγίσεις:

1. Data carrier objects.

Τα objects μας είναι απλά data carriers. Παράλληλα με τα object μας έχουμε manager/controller/whatever classes οι οποίες αναλαμβάνουν όλες τις CRUD λειτουργίες - συνεπώς, την επικοινωνία με το DAL. Οι ίδιοι managers (μην αναφέρω το μακρινάρι πάλι) είναι υπεύθυνοι για τη δημιουργία / population των objects και ενδεχομένως των collections μας. Αν ένα property κάποιου object αναφέρεται σε collection από άλλα objects, ο "manager" είναι υπεύθυνος να το κάνει populate.

Παραλλαγή 1.1: Ενας τεράστιος manager με όλες τις CRUD λειτουργίες για όλα τα objects μας, singleton. (cohesion:high, coupling: low)
Παραλλαγή 1.2: Ενας τεράστιος manager με όλες τις CRUD λειτουργίες για όλα τα objects μας, shared. (cohesion:high, coupling: low)
Παραλλαγή 1.3: Πολλοί managers, ένας για κάθε object μας, όλοι shared. (cohesion:low, coupling: high - μεταξύ των managers)
Παραλλαγή 1.4: Πολλοί managers, ένας για κάθε object μας, όλοι instance-based. (cohesion:low, coupling: high - μεταξύ των managers)
Παραλλαγή 1.5: Πολλοί managers, ένας για κάθε object μας, όλοι singleton. (cohesion:low, coupling: high - μεταξύ των managers)

Παράδειγμα:

Εχουμε τις εξής κλάσεις:
Customer
CustomerManager

Η δημιουργια ενός νέου customer object που τραβάει τα δεδομένα του από τη βάση γίνεται από τον CustomerManager κάπως έτσι (παραλλαγή 1.4):

Dim cm as New CustomerManager()
Dim cust as Customer()

cust = cm.GetCustomerById(34)

Εσωτερικά, ο Customer έχει ένα Orders property που αποτελεί ένα collection από Order objects. Υπεύθυνος για το population του Orders collection είναι ο CustomerManager (να γράψω sample κωδικα; μπα. Πιστεύω να το καταλαβαίνετε)

2. "Εξυπνα" και "παχιά" objects - intermediate approach

Τα objects μας είναι "ολίγον εξυπνα" όσον αφορά στο data access. Υπάρχουν οι προαναφερθέντες "managers", οι οποίοι όμως καλούνται από τα ίδια τα objects. Ετσι, κάθε object που περιέχει άλλα objects κάνει populate μόνο του τον εαυτό του και τα collections που τυχόν περιέχει.

Παραλλαγές: Ολες οι παραπάνω, όταν έχουμε instance-based managers τα objects είναι υπεύθυνα για το initialization / disposal των managers αυτών.

Παράδειγμα :

Dim cust as New Customer(34) 'Ας πούμε οτι έχουμε overloaded constructors εδώ και αυτός το γεμίζει κιόλας

cust.Name = "Lalakis"
cust.Save()

Εσωτερικά, για να δώσουμε π.χ. την cust.Orders property θα είχαμε τον εξής κώδικα για το property backer variable:

Dim cm as New OrderManager()

_orders=cm.GetOrdersByCustomer(Me.CustomerId)

 

3. "Εξυπνα" και "παχιά" objects - full approach

Εδώ δεν υπάρχουν "managers". Τα objects κάνουν απευθείας κλήσεις στο DAL για τις λειτουργίες τους.

Παραλλαγή 3.1: Οι methods των objects που κάνουν κλήσεις στο DAL είναι shared.
Παραλλαγή 3.2: Οι methods των objects που κάνουν κλήσεις στο DAL είναι instance-based.

Παράδειγμα (παραλλαγή 3.1):

Dim cust as Customer()

cust = Customer.GetById(34)
cust.Name = "Lalakis"
Customer.Save(cust)

Ερωτήματα:

- Ειναι ορθές οι παραπάνω προσεγγίσεις ή κάποιες ειναι προβληματικές (κατά την άποψή σας πάντα); Εσείς τι επιλέγετε ανάλογα με την περίσταση;
- Υπάρχουν άλλες προσεγγίσεις που τυχόν χρησιμοποιείτε (σε απλά σενάρια ή ακόμα και σε περίπλοκα) που δεν αναφέρονται εδώ;

Να ζητήσω συγνώμη που τα δείγματα κώδικα είναι γραμμένα "στο πόδι" και από το μυαλό μου, και ίσως δεν δείχνουν επακριβώς τα πράγματα όπως θα ήθελα. Το θέμα είναι αρκετά μεγάλο και θέλω απλά να κάνω την αρχή για συζήτηση και όχι να απαριθμήσω ολες τις δυνατές προσεγγίσεις. Ομως πιστεύω οτι είναι ιδιαίτερα χρήσιμο να συζητήσουμε τι είδους προσεγγίσεις ακολουθούμε σε κάθε περίπτωση. Και ναι, πιστεύω οτι και τα ORMs είναι μέσα στο παιχνίδι, όμως ας δούμε τι γίνεται ΧΩΡΙΣ αυτα. Με την έννοια οτι ξέρω οτι ο Παναγιώτης (και με το δίκιο του) θα μας προτείνει να βάλουμε ένα nHibernate σε κάποιες από τις παραπάνω περιπτώσεις. Ομως, θα ήθελα να συζητήσουμε για την προσέγγιση με βάση τα εργαλεία που μας δίνει η Microsoft, και όχι με βάση τρίτα βοηθήματα.

 

 

 

---

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

DotSee Web Services

Εδώ βάζεις κάμποσα διαφορετικά ερωτήματα:

1. Ποιός γεμίζει τα αντικείμενα? Τα ίδια τα αντικείμενα ή κάποιος manager?
2. Ποιός είναι υπεύθυνος για την αποθήκευση? Ποιός καλεί την Save? Τα αντικείμενα τα ίδια ή κάποια άλλη κλάση καλεί τον manage?
3. Πως αποθηκεύω collections και associated objects?
4. Πως επικοινωνεί το Middle tier με το data tier? Βλέπει το data tier τα αντικείμενα του middle, ή χρησιμοποιώ ενδιάμεσα data objects?
5. Πως θα βρώ τους managers?

Τα ORMs καλύπτουν μόνο το πρώτο και δεύτερο ερώτημα. Τα άλλα τρία παραμένουν, είτε χρησιμοποιήσει κανείς ORM είτε όχι. Επίσης δεν αντιμετωπίζονται και άλλα θέματα όπως locking, concurrency, caching, τα οποία αντιμετωπίζονται επίσης από τα ORMs.
Όσον αφορά το πρώτο κομμάτι, η δουλειά θα γίνει πολύ ευκολότερη χρησιμοποιώντας generics. Μπορείς με 1 manager κλάση να κάνεις την δουλειά των διαφορετικών managers. Ο κώδικας των managers θα είναι επαναλαμβανόμενος σε πολύ μεγάλο ποσοστό. Αν φτιάξεις ένα generic manager θα γλυτώσεις πολλούς μπελάδες.
Το κομμάτι που δεν είναι κοινό είναι τα queries που θα κάνεις στη βάση και το mapping των πεδίων που διαβάζεις από τη βάση σε properties των αντικειμένων. Αν δεν θέλεις να φτιάξεις mapping μηχανισμούς (πάμε προς ORM πάλι) μπορείς να περνάς στο generic mapper πέρα από τον τύπο του αντικειμένου που θέλεις να φτιάξει, και μία κλάση/delegate/anonymous method η οποία θα κάνει το mapping από τα πεδία στο αντικείμενο και το ανάποδο.
Η κλάση του manager μπορεί να μοιάζει κάπως έτσι:

class PersistenceManager<T,KEY> where new()
{
   public PersistenceManager(MappingDelegate ObjectToDB,MappingDelegate DbToObject){...}
   public T GetByID(KEY key)
   {
      T newObject=new T();
      ...
      DbToObject(newObject,dataset);
      ...
      return T;     
   }
   public void Save(T anObject)
   {
      ...
      ObjectToDB(anObject);
      ...
   }
}

ή έτσι

class PersistenceManager<T,KEY,MAPPER> where MAPPER:IMapper, new()
{
   IMapper mapper=new MAPPER();
   public PersistenceManager(){...}
   public T GetByID(KEY key)
   {
      T newObject=new T();
      ...
      mapper.DbToObject(newObject,dataset);
      ...
      return T;     
   }
   public void Save(T anObject)
   {
      ...
      mapper.ObjectToDB(anObject);
      ...
   }
}

Τώρα, αρχίζουν οι επιλογές. Οι μέθοδοι mapping μπορούν να βρίσκονται στα αντικείμενα, αν και δεν τρελαίνομαι με την ιδέα καθώς το αντικείμενο πρέπει να ξέρει από βάση. Από την άλλη έτσι μπορείς να φτιάξεις ένα manager δίνοντας του μόνο τον τύπο του αντικειμένου.

Άλλη λύση είναι να έχεις "κάπου" έτοιμα αντικείμενα managers, με μεθόδους mapping που έχεις ορίσει εσύ. Εδώ μπλέκει το 4ο ερώτημα, που θα βρεις τους managers? Μπορείς να τους φτιάξεις κατά το initialization της εφαρμογής αλλά αυτό θα σε αναγκάσει να φορτώσεις πολλούς managers χωρίς λόγο, ειδικά αν έχεις πολλούς τύπους αντικειμένων. Μία καλύτερη λύση είναι να φτιάξεις μία κλάση ManagerFactory με μία μέθοδο GetManager<T,KEY,MAPPER>() η οποία θα επιστρέφει τον κατάλληλο manager. Μάλιστα, μπορεί να τον κρατάει και σε κάποιο private collection έτσι ώστε να τον δημιουργήσει μόνο την πρώτη φορά που θα δημιουργηθεί και να το επιστρέφει μετά.

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

Το ερώτημα 4, πως αποθηκεύω collections και associated objects, είναι το σημείο στο οποίο τα ORMs μας γλυτώνουν πολύ δουλειά. Εδώ τώρα έχουμε ένα μικρό προβληματάκι. Με ένα ORM, του λέμε σώσε ένα αντικείμενο και αυτό θα πάει να σώσει όσα άλλα αντικείμενα χρειάζεται, καθώς του το έχουμε πει εμείς στο mapping αρχείο. Χωρίς ORM, έχουμε δύο επιλογές, οι οποίες όμως περιπλέκουν το προηγούμενο ερώτημα

1. Το ίδιο αντικείμενο θα πρέπει να κάνει το save και να καλέσει την save στα αντικείμενα των collections. Έτσι όμως, γίνεται δυσκολότερος ο έλεγχος όταν εμπλέκονται πολλά αντικείμενα σε μία διαδικασία. Από που ξεκινάμε και που σταματάμε το save?
2. Κάποιος τρίτος αναλαμβάνει να καλέσει τις save των εμπλεκόμενων αντικειμένων.

Εδώ δεν υπάρχει εύκολη απάντηση, και πάλι έχει να κάνει με το πως χρησιμοποιούμε τα αντικείμενα. Μπορούμε βέβαια να συνδυάσουμε τις δύο λύσεις, δίνοντας μία Save στα αντικείμενα, και επιτρέποντας και το ανεξάρτητο save όταν χρειάζεται.

Το ερώτημα 4 έχει πάντως εύκολη απάντηση. Κάνουμε ότι μας βολεύει περισσότερο. Αν, σχεδιάζοντας την εφαρμογή, διαπιστώσουμε ότι η σχεδίαση των αντικειμένων κάνει δύσκολη την αποθήκευση τους, μπορούμε να χρησιμοποιήσουμε data objects αντί για τα ίδια τα middle tier objects. Επίσης, αν τα middle tier αντικείμενα κουβαλάνε πολλά "μπαγκάζια", πεδία που δεν αποθηκεύονται, calculated fields, ίσως είναι ευκολότερο να χρησιμοποιηθούν data objects. Τα middle tier objects θα ξέρουν πως να φτιάξουν και να γεμίσουν από τα data objects. Γενικά πάντως, είναι καλύτερο τα data objects να χρησιμοποιούνται μόνο όταν είναι αναγκαία και όχι νωρίτερα.

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

---

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

Παναγιώτη ήσουν όπως πάντα εξαιρετικά περιεκτικος. Επειδή όμως (οπως το υποψιαζόμουν), το δικο σου σενάριο περιλαμβάνει και τα ORMs, θα ήθελα να ακούσω και non-ORM προσεγγίσεις (και φυσικά πάντα real-life) από άλλους συναδέλφους. Η προσέγγισή σου με τα generics είναι ιδιαίτερα εύστοχη, και όντως είναι πολύ ενδιαφέρουσα.

Και για να σε προλαβω (μια και είχαμε και ιδιαιτέρως αυτή τη συζήτηση), θα συμφωνήσω οτι στο τέλος της ημέρας αν θέλεις να κάνεις περίεργα πράγματα πάς σε ORM - δεδομένου οτι έχεις λόγο να το χρησιμοποιήσεις. Αλλα προσπάθησα να κρατήσω τις αρχικές προσεγγίσεις όσο πιό απλές γίνεται γιατί είμαι ΣΙΓΟΥΡΟΣ οτι αρκετοί συνάδελφοι έχουν πέσει σε κώδικα που χρησιμοποιεί κάποια από αυτές και οι ίδιοι ίσως έχουν χρησιμοποιήσει / αναγκαστεί να χρησιμοποιήσουν κάποια τέτοια. Εκεί θα ήθελα λοιπόν να μάθω τι γίνεται.

Παντως, για να είμαστε δίκαιοι, έχω (ξανα) κατεβάσει το nHibernate και μάλλον θα αρχίσω να (ξανά) πειραματίζομαι. Βοήθησε και η παρουσίασή σου στο Community Event #2. :)

---

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

DotSee Web Services

Μα δεν αναφέρθηκα σε ORM! Όσα έγραψα είναι χωρίς ORM! Απλά ανέφερα ότι αυτά είναι έτοιμα σε ORM!

Αν εννοείς τα mapping functions, τα ονόμασα έτσι γιατί αυτό κάνουν ουσιαστικά. Διαβάζουν ένα dataset ή datareader και γεμίζουν ένα object. Αν δεν θέλουμε ένα περίπλοκο μηχανισμό αντιστοίχισης ονομάτων properties σε table columns, η ευκολότερη λύση είναι να φτιάξουμε δύο functions, ένα που διαβάζει από τη βάση και γεμίζει ένα αντικείμενο, και ένα που κάνει το αντίστροφο.

Από εκεί και πέρα, θα υπάρχει πολύς κοινός κώδικας για διαχείριση connections, concurrency, transactions ο οποίος μπορεί να μαζευτεί σε μία generic κλάση. Έτσι, αντί να φτιάχνουμε ένα καινούριο manager για κάθε νέα κλάση, χρειαζόμαστε μόνο τα δύο mapping functions.

---

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

Οκ αλλα δεν άκουσα κανέναν άλλον! Τι γινεται; Τοσο trivial ειναι το θέμα που δεν χρήζει απαντήσεων; :)

---

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

DotSee Web Services

ΟΚ, θα παραθέσω και εγω την δική μας προσέγγιση:

1. Δημιουργήσαμε, ενα dll (Data access tier) το οποίο διαχειρίζετε μία εγραφή σε εναν πίνακα (read, save(INSERT-UPDATE), delete), κάτι σαν την Entity του Enterprice Library.  Αυτό το Library είναι δυναμικό (μπορεις να προσθαφαιρέσεις column)

2. Δημιουργία (μέσο CodeDom), ενδιάμεσου Class (RecordClass) με properties της κολώνες το πίνακα (Inherit from Entity).

3. Δημιουργία Data Class (Middle tier), που περιέχει ολο το buissnes logic (customer with collection απο order κ.τ.λ).

Αρα ειμαστε στην κατηγορία "3 Εξυπνα και παχία object - Full approach"..... Μαλλον.

PS: typed DataSet?!?!?! NO WAY MATE!!

Nassos

---

"Success is the ability to go from one failure to another with no loss of enthusiasm."
Winston Churchill

"Quality means doing it right when no one is looking."
Henry Ford

Να ξαναπροσδιορίσουμε το θέμα; Μιλάμε για

- data access layer (DAL);

- data transfer objects (DTO);

- data mapping;

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

Αν τα βάλουμε όλα μαζί, τότε μπορεί κανείς να ανεφέρει και άλλες πτυχές, π.χ. communication θέματα (π.χ. .net remoting, web services κ.α.) και όχι κατέβει στο κεφάλι του καθενός.

---

Dimitris Papadimitriou Software Development Professional

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

Το αντίθετο. Μιλάμε για όλα αυτά μαζί ως συνολική προσέγγιση. ΟΧΙ για DAL, αλλά για τρόπους επικοινωνίας με αυτό. Περισσότερο δηλαδή μιλάμε για DTO-Data Mapping.

Ο σκοπός της δημοσίευσης ήταν να το δούμε από λίγο πιό "ψηλά" όσον αφορά στις γενικές μεθοδολογίες επικοινωνίας business/dal.

Για τις άλλες πτυχές, επέμεινα να το περιορισω σε windows forms / simple application και όχι σε ειδικά σενάρια όπως remoting οπου οι επιλογές καθορίζονται κυρίως από εξωγενείς παράγοντες. Αν παρ'όλα αυτά φαίνεται ακόμα πολύ γενικό, να το εξειδικεύσουμε.

---

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

DotSee Web Services

papadi,

για το post μου πάει η απαντησή σου?

Nassos.

---

"Success is the ability to go from one failure to another with no loss of enthusiasm."
Winston Churchill

"Quality means doing it right when no one is looking."
Henry Ford

Nassos.NET wrote:

papadi, για το post μου πάει η απαντησή σου? Nassos.

Για όλα τα posts του thread, οπότε και για το δικό σου. Μην το παίρνεις προσωπικά!

---

Dimitris Papadimitriou Software Development Professional

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

οχι φιλε, σε καμία δεν το περνω προσωπικα! δεν με προσβαλες!!, απλα αν ηταν για το δικο μου, να τεκμηρίωνα!!!lool

Προσωπικα θα το επαιρνα αν με ήξερες προσωπικά, και μου εριχνες κανα κιλο μπινελικια!!

Nassos

---

"Success is the ability to go from one failure to another with no loss of enthusiasm."
Winston Churchill

"Quality means doing it right when no one is looking."
Henry Ford

Πιστεύω μου είναι πως ένα object δεν θα πρέπει να έχει ιδέα τι γίνεται έξω από αυτό. Οπότε όπως καταλαβαίνεις δεν ακολουθώ στην σχεδίασή μου το εξής :

myCustomer.Save

Αλλα :

myDBManager.Save(Customer)

Τώρα εδώ τίθεται το εξής ερώτημα. Ποιος θα γνωρίζει το SQL Statement με το οποίο θα αποθηκεύεται το myCustomer. Όπως ανέφερα ένα object δεν θα πρέπει να έχει ιδέα σε ποιο περιβάλλον τρέχει και λέγοντας περιβάλλον δεν εννοώ windows ή κάτι άλλο αλλά την εφαρμογή μας και τι κάνει αυτή. Ένα object όμως πάντα θα γνωρίζει πως θα σώζεται, πως θα εκτυπώνεται, είναι υπεύθυνο αυτό να δώσει τις σωστές οδηγίες στο περιβάλλον μέσα στο οποίο τρέχει για να σωθεί π.χ στην βάση ή να εκτυπωθεί. Δεν θα αναλάβει όμως αυτό την διαδικασία για να σωθεί κάπου ή να εκτυπωθεί.

Η συγκεκριμένη προσέγγιση έχει πολλά πλεονεκτήματα που ίσως στην αρχή να μην φαίνονται. Έχουμε φτιάξει μία εφαρμογή και κάποια στιγμή ο πελάτης μας θέλει στν εφαρμογή να ενσωματώσει δικαιώματα χρηστών. Αυτό που έχουμε να κάνουμε είναι να πάμε στους Managers και να προσθέσουμε μόνο εκεί των σχετικό κώδικά. Τα objects μας δεν έχουν ιδέα ότι μέσα στο περιβάλλον στο οποίο τρέχουν υπάρχει αυτή η νέα απαίτηση...

Επόμενη απαίτηση του πελάτη είναι να υπάρχει ένας τρόπος παρακολούθησης το τι κάνει ο κάθε χρήστης στην εφαρμογή. Πάω πάλι στους Managers και προσθέτω εκεί των σχετικό κώδικα που ίσως να δημιουργεί κάποια logging αρχεία ή να ενημερώνει το LogView των Windows. Ή σου λέει ξέρεις κάτι μέχρι τώρα η επαφή με τους πελάτους ήταν να τους εκτυπώνω την κατάστασηή τους και να τους την στέλνω. Θα ήθελα σε παρακαλώ να μου προσθέσεις την δυνατότητα να μπορώ να του στέλνω την καρτέλα του και με email. Αυτό που θα είχες να κάνεις είναι να πας στον ExportΜanager και να έβαζες εκεί αυτό που πρέπει να βάλεις.

Οπότε όπως καταλαβαίνεται παίζω πολύ με interfaces.

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

Τουλάχιστον σε αυτό το συμπέρασμα κατέληξα εγώ και με αυτόν τον τρόπο δουλεύω.

Μερικές ερωτήσεις επάνω σε αυτό:

Ο manager σου αναλαμβάνει να διαχειριστει και τυχόν collections του object που διαχειρίζεται;

Επίσης, ο manager είναι ένας, πολλοί, shared ή instance;

Πώς δημιουργείς με αυτή την προσέγγιση ένα νέο, άδειο object;

---

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

DotSee Web Services

Εγώ πάλι ακολουθώ κάτι στην μέση θα έλεγα.
Έχω χωρίσει το DatabaseEngine απο την υπόλοιπη εφαρμογή.Το κάθε αντικείμενο, έχει δικές του methods (Save,Insert Κλπ) μέσα στις οποίες κάνει επεξεργασία σύμφωνα με το bussiness logic και αντίστοιχα καλεί method απο το DatabaseEngine ώστε να σώσει δεδομένα.Όταν θέλει να διαβάσει δεδομένα και να γεμίσει, το κάνει με τον ίδιο τρόπο. Καλεί οτιδήποτε χρειάζεται απο την βάση και αντίστοιχα κάνει το fetch/assign μέσα στον εαυτό του.Εάν προστεθεί κάποιο νέο πεδίο, έχω μόνο να το προσθέσω στο σημείο όπου γίνεται το fetch/assign και πουθενά αλλού. Έτσι δεν φτιάχνω κάποιο dynamic τρόπο, γιατί πιστεύω οτι δεν μου χρειάζεται.Έτσι κι αλλοιώς απο το να ζητήσω απο κάποιον generator να μου κάνει πάλι generate τον κώδικα, συμπληρώνω τις γραμμές απο μόνος μου.Όταν το αντικείμενο καλεί την method για να γεμίσει τον εαυτό του σαν carrier χρησιμοποιώ ένα dummy dataset reference το οποίο γεμίζει απο κάποιον adapter (ο οποίος γίνεται dynamic generate) σύμφωνα με τις παραμέτρους που του πέρασα.

Την εξακρίβωση των δικαιωμάτων την κάνω πριν καλέσω την method.Έτσι μπορώ να πετύχω να ΜΗΝ εμφανίσω καθόλου κάποια κουμπιά/functions στον χρήστη ο οποίος δεν έχει δικαίωμα να τα δει (χωρίς να χρειάζεται να κάνω διπλούς ελέγχους) απο το να χρειάζεται να φορτώσω το Object, να καλέσω το method και μετά να διαπιστώσω ότι ο χρήστης δεν έχει πρόσβαση σε αυτό και να εμφανίσω μήνυμα λάθους.Για τα δικαιώματα κλπ, χρησιμοποιώ το Security Namespace και κάνω extend διάφορα classes τα οποία χρειάζομαι για να τα φέρω στα μέτρα μου.

---

Παναγιώτης Κεφαλίδης

"Για να επιτύχεις, θα πρέπει το πάθος σου για την επιτυχία να είναι μεγαλύτερο απο τον φόβο σου για την αποτυχία"

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

cap wrote:

Μερικές ερωτήσεις επάνω σε αυτό: Ο manager σου αναλαμβάνει να διαχειριστει και τυχόν collections του object που διαχειρίζεται; Επίσης, ο manager είναι ένας, πολλοί, shared ή instance; Πώς δημιουργείς με αυτή την προσέγγιση ένα νέο, άδειο object;

Επειδή και εγώ δουλεύω όπως και ο infoCenter, απαντώ στις ερωτήσεις σου έχοντας στο μυαλό μου τη δική μου προσέγγιση. Άλλωστε, συζήτηση να γίνεται.
Για μένα το DTO μου είναι το dataset. Και έχω όπως ο infoCenter μια γενική κλάση που αναλαμβάνει να αποθηκεύσει οποιοδήποτε object (dataset). Η κλάση αρχικοποιείται κάθε φορά από την αρχή για την αποθήκευση ενός dataset, μια φορά όμως αν το dataset περιέχει πολλές εγγραφές σε πολλούς πίνακες. Οπότε δεν είναι singeton ή shared, αλλά καθαρά instances κάθε φορά, μια που δεν έχουν state.
Ένα layer που υπάρχει στην κλάση αναλαμβάνει να ελέγξει δικαιώματα (π.χ. αν ο χρήστης μπορεί να κάνει insert/update/delete σε ένα πίνακα).
Η αρχική κλάση διαχειρίζεται αποθήκευση πολλών πραγμάτων ταυτόχρονα (π.χ. προσθήκη μιας εγγραφής, χρήση του auto increment για τις child εγγραφές, διαγραφή από άλλο πίνακα). Η σχέση μεταξύ των πινάκων του dataset ορίζεται από ένα object oriented query, το οποίο περιλαμβάνει τους πίνακες που θα αποθηκευτούν, τις σχέσεις μεταξύ τους, κριτήρια (όπως αυτά του nhibernate) στην περίπτωση ανάγνωσης εγγραφών.
Ένα άλλο layer στο όλο σύστημα αναλαμβάνει να καλέσει υλοποιήσεις abstract κλάσεων (μια για κάθε πίνακα) οι οποίες περιλαμβάνουν κώδικα τύπου BeforeInsert, AfterInsert, BeforeUpdate, AfterUpdate κλπ, οι οποίες είναι προεραιτικές και μπορεί να περιέχουν business ελέγχους ή ενέργειες.
Ένα άλλο layer αναλαμβάνει την καταγραφή της δραστηριότητας (loging).
Ο αδύναμος κρίκος είναι το dataset. Θα ήθελα να το αντικαταστήσω με μια δική μου υλοποίηση typed dataset, χρησιμοποιώντας κάποιο code generator. Ουσιαστικά καλύτερα αντικείμενα που θα έχουν από κάτω όμως ένα dataset με όλα τα πλεονεκτήματά του (getchanges, original values κ.α.)
Στα υπέρ είναι η ταυτόχρονη αποθήκευση σε πολλούς πίνακες, σε ένα transaction πράγμα χρήσιμο σε client/server εφαρμογές, μια που μειώνει τα roundtrips στο δίκτυο.
Επειδή δουλεύω με client/server το caching γίνεται σε άλλα επίπεδα. Ο manager αυτός δουλεύει πάντα με καθαρά δεδομένα.
Ορίστε ένα παράδειγμα (ψευδοκώδικας):
Dim myQuery As New Query(MyTable)
myQuery.AddJoin(MyChildTable, MyChildTable.fkMyTable)   ' define child object and related column to the parent table
myQuery.AddJoin(MyChildTable2, MyChildTable2.fkMyTable)
myQuery.Criteria = new Criterio(myfield, IsGreaterThan, 54)
' get data
Dim dataManager as new datamanager
Dim data as dataset=datamanager.getdata(myquery)
' use data, make changes, bind to UI, send to client etc.
data.myChildTable(0).myField=5
' update
Dim dataManager2 as new datamanager ' the same of different manager can be used (not recommended to keep reference to this object)
dataManager2.Update(myQuery, data)

---

Dimitris Papadimitriou Software Development Professional

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