Design & Architecture

Απ: Επικοινωνία Middle-Tier - DAL και πιθανές προσεγγίσεις

Παναγιώτης Καναβός — Wed, 09 May 2007 07:21:14 GMT

Ο Δημήτρης έχει δίκιο. Κολλώντας μία ασαφή ερώτηση σου σε ένα thread που έχει ουσιαστικά κλείσει, οι πιθανότητες να πάρεις απάντηση είναι ελάχιστες. Όσον αφορά την αρχική σου ερώτηση, δεν είναι δύσκολη, αλλά υπερβολικά ασαφής. Ποιές καταχωρήσεις θέλεις να γίνονται μαζί? Τί εννοείς να γίνονται μαζί? Τί εννοείς καταχωρήσεις? Χρησιμοποιείς κλάσεις, datasets, τί? Παραδείγματα βιβλίου?

Από τη στιγμή που έχεις ήδη τα βιβλία και αν το πρόβλημα σου είναι να καταλάβεις τα παραδείγματα, θα πρότεινα απλά να τα προσέξεις περισσότερο. Μήπως έχεις φτιάξει μία εικόνα στο μυαλό σου και προσπαθείς να ταιριάξεις το βιβλίο σε αυτή? Η ανάπτυξη n-Tier εφαρμογών διαφέρει αρκετά από την ανάπτυξη απλών φορμών. Θα πρέπει εσύ να προσαρμοστείς σε όσα σου λέει το βιβλίο, όχι να προσαρμόσεις το βιβλίο σε όσα νομίζεις.
Τα παραδείγματα των βιβλίων είναι πάντα απλοποιημένα. Αν δεν μπορείς να τα καταλάβεις, θα έχεις μεγάλο πρόβλημα στην ανάπτυξη μίας εφαρμογής. Επιπλέον, όπως σου είπε και ο Kelman, κανένα βιβλίο δεν μπορεί να καλύψει τα πάντα. Θα πρέπει να διαβάσεις και το MSDN, το οποίο καλύπτει σχεδόν κάθε τομέα.

Ίσως τέλος απλά να χρειάζεσαι πιο βασικά πράγματα από το πως να φτιάξεις μία N-TIER εφαρμογή. Η ερώτηση που έκανες δεν έχει τίποτε να κάνει με N-tier, αν και δεν κατάλαβα ακριβώς τι εννοείς. Προσπαθείς να αποθηκεύσεις αντικείμενα? Πίνακες? Τί? Μήπως πρέπει να ξεκινήσεις με ένα εισαγωγικό βιβλίο για VB.NET πριν περάσεις σε N-tier?

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

Απ: Επικοινωνία Middle-Tier - DAL και πιθανές προσεγγίσεις

Dimitris Papadimitriou — Tue, 08 May 2007 22:49:53 GMT

Προσπάθησε να διατυπώσεις ακριβώς αυτό που θέλεις να κάνεις σε ένα νέο thread και βλέπουμε.

Ποια είναι ακριβώς η ερώτηση;

Απ: Επικοινωνία Middle-Tier - DAL και πιθανές προσεγγίσεις

Ηλίας Κεκάκος — Tue, 08 May 2007 22:11:51 GMT

Γειά σας παιδιά.

Είμαι ένας από τους πολούς που προσπαθούν να μάθουν να γράφουν N-TIER εφαρμογές σε VB.NET. Έχουν πέσει στα χέρια μου κάποια βιβλία τα οποία αναπτύσουν μία εφαρμογή και ταυτόχρονα προσπαθούν να σου μάθουν πως γίνετε αυτό. Φαίνετε όμως ότι έχω κάποια κενά και δεν μπορώ να καταλάβω πως μπορώ να ολοκληρώσω τα παραδείγματα αυτά σύμφωνα με τον τρόπο που θέλω να γίνονται οι καταχωρήσεις, πχ όχι μία-μία αλλά όλες μαζί (όπως κάνουμε με ένα Dataset). Έχω ξαναθέσει την ερώτηση αυτή αλλά απάντηση δεν πήρα, για να είμε ακριβής πήρα μιά απάντηση από τον KELMAN. Από την απάντησή του αλλά και από τις μη απαντήσεις των υπολοίπων καταλαβαίνω ότι ζητάω κάτι δύσκολο που μπορεί να γίνει μέσω του forum. Δεν ξέρω ίσως ζητάω πολλά, αλλά αν υπάρχει κάποιος άλλος τρόπος πχ μέσω email και κάποιος έχει το χρόνο να το κάνει θα του ήμουν υπόχρεως.

Thanks

Απ: Επικοινωνία Middle-Tier - DAL και πιθανές προσεγγίσεις

anjelinio — Tue, 12 Dec 2006 20:07:27 GMT

[ ... είμαι σε άδεια, και τριγύρναγα σαν το τουριστάκι την Αθήνα με το Μετρό για αλλαγή, και έχασα αυτό το thread απ'την αρχή ... προσπαθώ να catch up όμως :P ]

Πρώτα να πώ ότι έχοντας στο παρελθόν αναγκαστεί να γράψω πολλές "GetByXXX" μεθόδους τόσο σε Managers όσο και σε "ημι-εξυπνα" Data Transfer Objects - τα οποία πολλοί θεωρούσαν Business Objects λόγω ενός υποτυπώδους validation και 3-4 rules, ΜΙΣΩ πλέον αυτό το approach. Πολύ copy - paste inheritance ρε παιδιά, brain-dead εργασία.

Επίης θεωρώ οτι τα typed datasets δεν είναι και τόσο "αισχρά" όσο πιστεύουν πολλοί. Σε ένα generic approach σαν αυτό που περιέγραψε ο Πάνος, τα typed datasets θα μπορούσαν κάλλιστα να είναι ο mapper, γι' αυτό φτιάχτηκαν άλλωστε.

Στη δουλειά τώρα. Μάλλον είμαστε τυχεροί σε αυτή την εταιρία, γιατί έχουν περάσει κατα καιρούς αρκετοί έξυπνοι άνθρωποι, ένας εκ των οποίων ο Μάριος Μαργαρίτης. Πολλοί απο εμάς - κι εγώ δεν τον πρόλαβα live στην εταιρία - τον έχουν δεί σε κάποιο DevDay πέρυσι να μιλαέι για DataAccess, έχοντας σαν παράδειγμα ένα DAL βασισμένο σε Typed Datasets. Αυτό, έχει δεν έχει περιορισμούς, το "κληρονομήσαμε" στη δουλειά, και είναι η αλήθεια οτι μας έχει βολέψει. DataSet persistence με μια γραμμή κώδικα.

Θεωρώ λοιπόν το typed dataset ως mapper και data transfer object μαζί. Επίσης, μου δίνει και πάμπολλα utilities όπως calculated πεδία, filtering, HasChanges (!!! ΠΟΛΥ ΣΗΜΑΝΤΙΚΟ !!!), και διάφορα άλλα μικρά καλούδια.

So far λοιπόν, έχω retrieval / persistence ( οκ, retrieval με πολύ basic criteria για τώρα, βάσει PKeys & relations στο DataSet, αλλά το συζητάμε μετά αυτό ), σε κάποια DTOs, σχεδόν automagically.

Τώρα, τα business objects. Μεγάλο κεφάλαιο. Αν πιστέψεις το φίλο μας το CSLA, to Customer είναι ένα business object. Κατα συνέπεια, στην περιγραφή του σεναρίου σου, τα ουσιαστικά μεταφράζονται σε "business objects". Διαφωνώ. Τα business objects θα έπρεπε να είναι πολύ πιο coarse grained - "μεγαλύτερα" αντικείμενα, τα οποία χρησιμοποιούν τα data transfer objects για να κάνουν τη δουλειά τους.

Στη δικιά μας δουλειά, ένα τέτοιο business object - ActivityDataSources τα λέμε εμείς - χρησιμοποιεί κατα μέσο όρο 4-5 typed datasets, τα οποία γίνονται load on demand όταν χρειάζονται, γίνονται persist μόνο όταν έχουν αλλαγές, και σύντομα θα γίνονται cached & discarded όταν πλέον δεν τα χρειάζεται κανείς. Όλα αυτά βάσει ενός generic manager μηχανισμού, όχι πολύ διαφορετικού απο αυτόν που προτείνει ο Παναγιώτης στην πρώτη σελίδα. ( Τύποις generic, γιατί είμαστε ακόμη παγιδευμένοι σε 1.1, αλλά μόλις "ροκανίσαμε" την πρώτη μπάρα στο παράθυρο !!! :D )

Τώρα στο άμεσο μέλλον, θα ήθελα πολύ να λύσω δύο "προβλήματα".

1. Fill τα typed datasets μου, όχι μόνο βάσει primary keys & relations, αλλά με πιο σύνθετα κριτήρια.
2. Να είμαι Persistence Medium Agnostic. Γιατί να ξέρω ΠΟΥ σώζονται αυτά που σώζωνται;

Αυτά τα δύο σκοπεύω να τα λύσω "μπλέκοντας" το DAL που κληρονομήσαμε απο το Μάριο, με το δικό μου, το πρώτο μου post σε αυτό το site πριν 1-μισι χρόνο, στο οποίο χρησιμοποιώ external configuration files για να ορίσω "data actions" τα οποία η εφαρμογή μου καλεί by name, και μου δίνουν κι αυτά μετά διάφορα καλούδια, κυρίως όμως caching, parameter validation & persistence medium adaptability.

Τελειώνοντας, να πώ οτι το Object Orientation , και γενικότερα η πληροφορική, είναι σαν πλαστελίνη. Δεν είναι "σκληρή επιφάνεια", μας δίνει ένα βασικό set of rules - mentallity καλύτερα, κι απο 'κεί και μετά είμαστε υποχρεωμένοι να "εξελιχθούμε" σε .. fluid καταστάσεις. Δε χρειάζεται τα ουσιαστικά στην πρόταση να είναι ντε και καλά objects, στην πραγματική ζωή. Αυτό ήταν και το βασικό misconception στους Java/EJB developers που τελικά κατάφερναν να κάνουν γαιδούρια να αγκωμαχάνε απο το βάρος ... 4 objects.

Καλή φάση η άδεια, ακόμα και αν είναι μόλις 3 μέρες !!!

Υ.Γ. Όλα τα παραπάνω, δεν αναιρούν την αμέριστη εκτίμησή μου στο O/R mapping, και αφορούν δεδομένα και objects τα οποία αναφέρονται directly σε "problem domain data" στη βάση δεδομένων μου. Όσον αφορά workflow & ui generation, όπου τα objects μου είναι by definition "έξυπνα", θα χρησιμοποιούσα O/R mapping χωρίς δεύτερη σκέψη. Βλέπετε, απο λύση σε λύση κι απο project σε project το structure αυτών των αντικειμένων δεν αλλάζει και τόσο συχνά. Απο την άλλη, η βάση ή καλύτερα το view του σχήματος της βάσης το οποίο καλείται να χρησιμοποιήσει η εφαρμογή για μια νέα λύση για πελάτη αλλάζει σχεδόν κάθε μήνα, με κάθε νέο project. Εκεί δε σε παίρνει να ξαναγράφεις κώδικα κάθε τόσο.

Απ: Επικοινωνία Middle-Tier - DAL και πιθανές προσεγγίσεις

infoCENTER — Tue, 12 Dec 2006 19:09:33 GMT

Γεια σας.

Συνεχίζω από εκεί που έμεινα με βάση της ερωτήσεις του Σωτήρη (cap) :

-------------------------------------------------------------------------------------------------------------

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

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

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

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

-------------------------------------------------------------------------------------------------------------

Όχι, ο Manager ή Managers που έχω δεν διαχειρίζονται collection των objects μου. Για αυτό υπεύθυνα είναι τα ίδια τα identities.

Έχω πολλούς Managers π.χ DBManager ο οποίος επικοινωνεί με το DAL. Άρα οποιοδήποτε object θέλει να κάνει κάτι στην βάση θα περάσει μέσα από εκεί. Έχω ExportManager, όπου μέσα από εδώ στέλνω τα objects τα οποία θέλουμε να εκτυπώσουμε, να μετατρέψουμε σε XML και γενικά οτιδήποτε έχει να κάνει με αποστολή δεδομένων έξω από την εφαρμογή μου. Φυσικά έχω και τον αντίστοιχο Import.

Τώρα τελευταία θέλω να προσθέσω μία νέα λειτουργία στις εφαρμογές μου χρησιμοποιώντας MSMQ. Μπορείτε να δείτε πόσο εύκολα μπορεί να γίνει αυτό;

Όλοι οι Managers είναι Singleton, προς το παρών. Όχι γιατί δεν θα μπορούσαν να γίνουν multiinstance αλλά προτιμώ να δουλεύω με Singleton.

H δημιουργία για ένα νέο άδειο object είναι δουλειά του Manager. Όπως ανέφερα ένα object δεν θα πρέπει να γνωρίζει το περιβάλλον και τις απαιτήσεις μέσα στο οποίο δουλεύει, θα πρέπει να γνωρίζει όμως βασικά πράγματα έτσι ώστε να δώσει οδηγίες στους Managers για το πως θα γίνει μία ενέργεια πάνω σε αυτό.

Οπότε στων κώδικά μου δεν υπάρχει το

Dim myCustomer as New Customer , αλλά

Dim myCustomer as Customer

myCustomer=myGeneralCollection.Create(AppObj.Customer)

myCustomer.LastName="Parissis"

myCustomer.FirstName="George"

myDBManager.Save(myCustomer)

Εδώ κάποιος θα μου πει. Ωραία και αν έγραφα Dim myCustomer as new Customer ποιο θα ήταν το πρόβλημα... Κανένα θα έλεγα. Σε αυτήν την φάση. Αν όμως πάμε λίγο πίσω στην κεντρική φράση "Κανένα object δεν θα πρέπει να γνωρίζει το περιβάλλον και τις απαιτήσεις απαιτήσεις, μέσα στο οποίο τρέχει" θα δούμε ότι ο κώδικας που έγραψα έχει σχέση με αυτό. Πολλές φορές ακόμα και στην ίδια την εφαρμογή, φανταστείτε πόσο μάλλον σε διαφορετικές, οι οποίες έχουν πουληθεί σε διαφορετικές γεωγραφικές περιοχές στην Ελλάδα ο χρήστης ίσως να θέλει να έχει διαφορετικές default τιμές στην δημιουργία κάποιων objects. Άρα το περιβάλλον τις εφαρμογής έχει μία απαίτηση. Δηλαδή όταν περνάω έναν νεο πελάτη και είμαι στην Αθηνα στην Πόλη να μου περνάει σαν default Αθήνα. Αυτό δεν είναι δουλειά του object να το γνωρίζει αλλά είναι πληροφορία που έχει να κάνει με την εφαρμογή και με τις ιδιαιτερότητες του χρήστη. Φυσικά ένα απλό παράδειγμα έφερα, μπορείτε να φανταστείτε πως μπορούν να επεκταθούν οι απαιτήσεις των χρηστών και σε άλλα πράγματα...

Όσο για Dataset που ανέφερε ο Δημήτρης (papadi). Μπορεί να χρησιμοποιηθεί και αυτό αλλά εγώ δεν το προτιμώ. Χρησιμοποιώ DataBinding σε όλες τις εφαρμογές και λίστες αλλά Dataset που θα ήταν και η φυσική επιλογή όχι. Οι λόγοι είναι δύο :

Resources... Είμαι απογοητευμένος μπορώ να πω... BindingList ανώτερο θα έλεγα.

Δεν ταιριάζει με την φιλοφοφία του OOP (αφού μιλάμε για OOP). Καλά εδώ θα μου πείτε, έλα ρε Γιώργο είναι λόγος τώρα αυτός;... Όχι και έχετε δίκιο... τι να κάνω όμως είμαι ψείρας...

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

Απ: Επικοινωνία Middle-Tier - DAL και πιθανές προσεγγίσεις

Dimitris Papadimitriou — Tue, 12 Dec 2006 18:09:49 GMT

cap wrote:
papadi wrote:

Η κλάση αρχικοποιείται κάθε φορά από την αρχή για την αποθήκευση ενός dataset, μια φορά όμως αν το dataset περιέχει πολλές εγγραφές σε πολλούς πίνακες. Οπότε δεν είναι singeton ή shared, αλλά καθαρά instances κάθε φορά, μια που δεν έχουν state.

Ωπ. Να μια αφορμή για ερώτηση: Αφού έχεις stateless πράγματα, γιατί δεν φωνάζεις shared methods μιας κλάσης που ΔΕΝ χρησιμοποιεί shared members; Γιατί αρχικοποιείς κάθε φορά ένα ολόκληρο object μόνο για ένα single call; (Ερώτηση είναι, πραγματικά, οχι κριτική). Εκτός βέβαια και αν κινείσαι με βάση την πρόβλεψη οτι θα σου επιτρέψει αυτή η υλοποίηση να προσαρμοστείς και σε πιό σκληρά σενάρια (com+, remoting και δεν συμμαζεύεται).

Γενικά, τι σε ώθησε να χρησιμοποιήσεις instances για αυτή τη λειτουργία;

Σωστές ερωτήσεις! Ομολογώ με προβλημάτισαν για λίγο! Η αλήθεια είναι ότι έχω πιο σκληρά σενάρια (client/server web services), αλλά και σε αυτή την περίπτωση θα μπορούσα να έχω shared methods. Επειδή όμως ο εν λόγω manager διαχειρίζεται όλα αυτά τα layers (data change loging, event loging, permission control, relationship management, sql generator) ήθελαν να έχω πρόσβαση σε κάποια από αυτά με τη μορφή properties, διαφορετικά θα είχα πολύπλοκα method signatures. Τώρα καλώ myManager.Update(myQuery, myData), διαφορετικά θα έπρεπε να έχω πολλά overloads.
Π.χ. δεν θέλω να γίνει έλεγχος δικαιωμάτων στην περίπτωση μιας εσωτερικής διαδικασίας που κάνει ο application server (web services), ή δεν θέλω να γίνεται data loging στην περίπτωση αποθήκευσης μεγάλο όγκου δεδομένων (θα καθυστερούσε πολύ η διαδικασία. στην περίπτωση αυτή κάνω data loging με άλλο τρόπο).
Δίνει επίσης την ευκαιρία, μια που έχει ένα δικό της connection με την βάση, να εκτελέσω δυο update πολύπλοκων αντικειμένων σε ένα db transaction. Το connection κλείνει στο dispose της κλάσης (using myManager and new manager .......... end using)
Οπότε με όλα αυτά τα πλεονεκτήματα που μου δίνει η κλάση αυτή θεωρώ ότι η δημιουργία νέων instances κάθε φορά που την θέλω δεν αποτελεί μειονέκτημα.

Απ: Επικοινωνία Middle-Tier - DAL και πιθανές προσεγγίσεις

cap — Tue, 12 Dec 2006 10:47:56 GMT

papadi wrote:

Η κλάση αρχικοποιείται κάθε φορά από την αρχή για την αποθήκευση ενός dataset, μια φορά όμως αν το dataset περιέχει πολλές εγγραφές σε πολλούς πίνακες. Οπότε δεν είναι singeton ή shared, αλλά καθαρά instances κάθε φορά, μια που δεν έχουν state.

Ωπ. Να μια αφορμή για ερώτηση: Αφού έχεις stateless πράγματα, γιατί δεν φωνάζεις shared methods μιας κλάσης που ΔΕΝ χρησιμοποιεί shared members; Γιατί αρχικοποιείς κάθε φορά ένα ολόκληρο object μόνο για ένα single call; (Ερώτηση είναι, πραγματικά, οχι κριτική). Εκτός βέβαια και αν κινείσαι με βάση την πρόβλεψη οτι θα σου επιτρέψει αυτή η υλοποίηση να προσαρμοστείς και σε πιό σκληρά σενάρια (com+, remoting και δεν συμμαζεύεται).

Γενικά, τι σε ώθησε να χρησιμοποιήσεις instances για αυτή τη λειτουργία;

Απ: Επικοινωνία Middle-Tier - DAL και πιθανές προσεγγίσεις

Dimitris Papadimitriou — Tue, 12 Dec 2006 04:26:56 GMT

Ξέχασα ίσως το πιο σημαντικό. Ο manager αυτός κάνει sql code generation για την επικοινωνία με τη βάση και αναλαμβάνει να δημιουργήσει κώδικα κατάλληλο για sql server ή oracle. Κάνει χρήση του sqlcommandbuilder ή oraclecommandbuilder με κάποιες τροποποιήσεις για τα autoincrement πεδία του sql server.

Απ: Επικοινωνία Middle-Tier - DAL και πιθανές προσεγγίσεις

Dimitris Papadimitriou — Tue, 12 Dec 2006 04:22:01 GMT

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)

Απ: Επικοινωνία Middle-Tier - DAL και πιθανές προσεγγίσεις

Panagiotis Kefalidis — Tue, 12 Dec 2006 03:59:25 GMT

Εγώ πάλι ακολουθώ κάτι στην μέση θα έλεγα.
Έχω χωρίσει το 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 τα οποία χρειάζομαι για να τα φέρω στα μέτρα μου.

Απ: Επικοινωνία Middle-Tier - DAL και πιθανές προσεγγίσεις

cap — Tue, 12 Dec 2006 03:23:05 GMT

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

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

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

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

Απ: Επικοινωνία Middle-Tier - DAL και πιθανές προσεγγίσεις

infoCENTER — Tue, 12 Dec 2006 03:16:19 GMT

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

myCustomer.Save

Αλλα :

myDBManager.Save(Customer)

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

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

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

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

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

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

Απ: Επικοινωνία Middle-Tier - DAL και πιθανές προσεγγίσεις

Nassos.NET — Tue, 12 Dec 2006 01:23:45 GMT

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

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

Nassos

Απ: Επικοινωνία Middle-Tier - DAL και πιθανές προσεγγίσεις

Dimitris Papadimitriou — Tue, 12 Dec 2006 01:16:47 GMT

Nassos.NET wrote:
papadi,

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

Nassos.

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

Απ: Επικοινωνία Middle-Tier - DAL και πιθανές προσεγγίσεις

Nassos.NET — Tue, 12 Dec 2006 01:00:13 GMT

papadi,

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

Nassos.