Αυτή είναι η πρώτη δημοσίευση μου στο forum του dotnetzone.gr, και θα ήθελα να θέσω το θέμα της επικοινωνίας μεταξύ 2 layers.

   Ας υποθέσουμε ότι έχουμε ένα 3-tier application (Interface, Business Logic Layer, Data Access Layer) . To BLL θέλει δεδομένα από το DDL, to DDL κάνει την δουλεία του παίρνει από την database τα δεδομένα, ποίος τρόπος είναι ο καλύτερος για να τα στήλη στο BLL,

α)να στήλη ένα Dataset/Datatable (typed, untyped νομίζω δεν έχει και πολύ σημασία) ή

β)να τα διαμόρφωση σε custom entity classes (δηλαδή αντί να στήλη ένα dataset με τους customers να στήλη ένα collection of customers class) και να σταλούν πίσω στο BLL.

Καλώς ήλθες φίλε μας.

Ανοίγεις ένα θέμα το οποίο έχει συζητηθεί με διάφορες παραλλαγές στο παρελθόν, και όχι μόνο για την επικοινωνία μεταξύ DAL και BLL. Ρίχοντας μια ματιά και σε προηγούμενες δημοσιεύσεις σίγουρα θα βρείς πολλές και ενδιαφέρουσες απόψεις.

Ομως, για το συγκεκριμένο σου ερώτημα, η απάντηση που πιστεύω οτι όλοι έχουμε στο μυαλό μας είναι η εξής: Αν το DAL ξέρει τα classes του BLL, τοτε έχουμε κυκλική εξάρτηση (το BLL ξέρει το DAL και το DAL ξέρει το BLL). Συνεπώς, η απάντηση που θα μπορούσα να δώσω είναι η εξής: Το DAL πρέπει να φέρει τα δεδομένα σε μια οικεία του μορφή (π.χ. datasets) και το BLL να αναλάβει να διαμορφώσει τις custom entity classes (αν χρησιμοποιεί τέτοιες) με βάση αυτά τα δεδομένα.

Ετσι (υποθέτουμε οτι έχουμε 3 tiers) το UI θα ξέρει το BLL, και το BLL θα ξέρει το DAL. Το DAL θα ξέρει μόνο το data store, και αυτό θα το κάνει να είναι ανεξάρτητο από το ποιός το καλεί.

Η υπόθεση σηκώνει "νερό" μόνο αν έχουμε n-tier αρχιτεκτονικές, αλλά και πάλι οι κυκλικές εξαρτήσεις είναι τζιζ. Φυσικά, μην μείνεις μόνο στη δική μου άποψη, γιατί είμαι σίγουρος οτι και άλλοι συνάδελφοι θα απαντήσουν εν καιρώ στο συγκεκριμένο ερώτημα.

---

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

DotSee Web Services

Ναί, όντως το θέμα αυτό το έχουμε κουβεντιάσει αρκετά και ιδιαίτερα στο πρώτο community event! (Και να δεις που θα φουντώσει εκ νέου :))

Τώρα, ως προς την ερώτησή σου, πιστεύεις ότι η B σχεδίαση θα σε βοηθήσει όταν χρειαστεί να γίνουν αλλαγές στο BLL? Θα πρέπει να κάνεις αλλαγές σε δύο σημεία... Καλύτερη είναι η Α σχεδίαση. Όσο πιο απλά και αφαιρετικά είναι τα layers τόσο το καλύτερο. Το DAL θα πρέπει να ενδιαφέρεται μόνο για το πως θα πάρει τα data από το data store. Αν σε "ενοχλεί" που το BLL πέρα από το business θα ασχολείται με το πως θα γυρίσει τα data σε entities μπορείς πάντοτε να απομονώσεις αυτό το functionality σε ένα ξέχωριστό layer που θα λειτουργεί ως adapter μεταξύ των δύο.

---

Vir prudens non contra ventum mingit

Το θέμα είναι μεγάλο και αρκετά σύνθετο.

Μπορείς να πάρεις μια ιδέα από τα παρακάτω άρθρα

http://www.informit.com/articles/printerfriendly.asp?p=31099&rl=1

http://msdn.microsoft.com/msdnmag/issues/05/08/CuttingEdge/default.aspx

Έως ένα βαθμό έχει να κάνει και με το background που έχει ο καθένας.

Γενικά νομίζω ότι υπάρχουν κάποια συγκεκριμένα camps

- Yπάρχει το camp της smalltalk που δίνουν μεγάλη βάση στα objects και στο σωστό object design.

Ατάκα "code must be close to the data" or code + data = objects

θεωρούν το persistence ως ένα αναγκαίο κακό!!!

-Υπάρχει το camp των database guys που δίνουν μεγάλη βάση στο erd τους. Yπάρχει σαφείς διαχωρισμός μεταξύ code and data και προσπαθούν να κρατούν και τα data και την λογική στην βάση

-Τέλος, υπάρχει και η μέση οδός που προσπαθούμε να συμβιβάσουμε και τους δυο κόσμους... (βλέπε Ο/R mapping)

Εγώ προσωπικά προσπαθώ να ακολουθώ πιστα BusinessObjects design, αλλα αφήνω και ένα escape path στον κόσμο του dataset και της sql (για τις δύσκολες περιπτώσεις...performance)

 

---

Palladinos Nick
Software Engineer
-----------------------
The limits of my language mean the limits of my world. (Ludwig Wittgenstein)

Θα συμφωνήσω με το φίλο palladin, με ένα μικρό "twist".

Εξαρτάται απο το πόσο "πλατφορμική" είναι η εφαρμογή σου. Σε περιπτώσεις που υπάρχει ένα "ξεκάθαρο" object-domain model το οποίο αλλάζει σε σχετικά μικρό βαθμό απο πελάτη/χρήση/feature σε πελάτη/χρήση/feature, πάμε για O/R Mapping,  με ιδιέταιρη προσοχή στο performance.

.. αν βέβαια μπλέξεις με "μπελάτη" και το schema σου αλλάζει ... κατά το δοκείν του εκάστοτε υπαλλήλου που ουδεμία σχέση έχει με το θέμα που καλείσαι εσύ να λύσεις ... go for datasets, ίσως αποδειχθεί πιο ευέλικτο.

Και φυσικά έχει πάντα να κάνει με το background σου, με τί έχεις ασχοληθεί στο παρελθόν και φυσικά ... πόσο χρόνο έχεις να το ψάξεις. Ένα κακό domain model θα σου βγάλει στνη πορεία πολλά περισότερα μερεμέτια απο ένα κακό typed dataset - νομίζω ...

Άντε και καλό μας βράδυ ...

---

Angel
O:]

Ένα hint για το πού πάνε τα πράγματα μπορεί να το πάρει κανείς παρατηρώντας κάποια ανεπαίσθητα στοιχεία: Το Validation Application Block του Enterprise Library v3 δουλεύει με κλάσεις. Το Policy Injection Application Block το ίδιο. Το Linq δημιουργεί αντικείμενα από queries.
Ο Hejlsberg μιλά για datasets χρησιμοποιώντας τον αόριστο.

Πέρα από αυτό, όταν έχεις να αντιμετωπίσεις μεταβαλλόμενες απαιτήσεις από πελάτη σε πελάτη, δεν μπορείς να χρησιμοποιήσεις ένα στατικό object model. Πρέπει να φτιαχτεί έτσι ώστε να μπορεί να μεταβάλλεται ανάλογα με τις απαιτήσεις, χωρίς να χρειάζεται να ξανακάνεις compile. Ευτυχώς, κάποια ORM το υποστηρίζουν αυτό, π.χ. το NHibernate επιτρέπει τον ορισμό δυναμικών properties τα οποία φορτώνονται σε ένα dictionary. Έτσι ορίζει κανείς τα business entities της εφαρμογής του στη φάση της ανάπτυξης αλλά μπορεί να τροποποιήσει τα δυναμικά properties απλώς αλλάζοντας το mapping file του ORM. Χρησιμοποιώντας μετά ένα workflow engine, όπως το WWF, μπορεί να αλλάξει και τη συμπεριφορά της εφαρμογής ανάλογα με τις απαιτήσεις.

Τα πράγματα είναι λίγο πιο περίπλοκα όταν πρέπει να αλλάξουν ακόμα και τα business entities. Τα περισσότερα ORM θεωρούν ότι οι κλάσεις υπάρχουν ήδη, κάτι λογικό καθώς δεν είναι εύκολο να δημιουργήσεις μία κλάση από το μηδέν κατά την εκτέλεση της εφαρμογής. Η χρήση CodeDom το επιτρέπει αυτό βέβαια, αλλά μπλέκει κανείς με τα permissions. Θα μπορούσε κανείς να φτιάξει μία και μοναδική κλάση, π.χ. BusinessEntity και να ορίσει δυναμικά properties για κάθε διαφορετικό business entity. Αυτό είναι σχετικά δύσκολο με το NHibernate, γιατί ουσιαστικά σημαίνει ότι ένα αντικείμενο μπορεί να φορτωθεί από πολλούς διαφορετικούς πίνακες. Μία λύση θα ήταν να χρησιμοποιήσει κανείς πολλά διαφορετικά mapping files του BusinessEntity σε διαφορετικό πίνακα κάθε φορά, δημιουργώντας ένα καινούριο Configuration αντικείμενο κάθε φορά. Τα πράγματα θα ήταν πολύ πιο εύκολα αν μπορούσε κανείς να ορίσει πολλαπλά mappings μεταξύ κλάσεων και πινάκων, όχι μόνο μία κλάση προς ένα mapping.

Το τελευταίο πράγμα που χρειάζεται να οριστεί είναι οι μέθοδοι του κάθε αντικειμένου. Ευτυχώς, χρησιμοποιώντας το Workflow Engine μπορεί κανείς να ορίσει τα business processes. Αυτό που μένει είναι οι πιο απλές μέθοδοι που κανονικά είναι αρμοδιότητα κάθε κλάσης, μέθοδοι που έχουν να κάνουν με συγκεκριμμένους υπολογισμούς κλπ. Εδώ μπορεί κανείς να χρησιμοποιήσει τεχνικές scripting, για να επιτρέψει την τροποποίηση της εφαρμογής ακόμη και στον πελάτη. Ή μπορεί να δημιουργήσει βιβλιοθήκες με τις μεθόδους που θέλει να έχει το κάθε business entity και να προσθέσει τις μεθόδους στο κάθε BusinessEntity σαν delegates. Ενδιάμεσα μπορούν να χρησιμοποιηθούν και άλλες τεχνικές, όπως τα DynamicMethods.

Τα πράγματα θα γίνουν πολύ πιο ενδιαφέροντα με τη C# 3.0 χρησιμοποιώντας δυνατότητες όπως τα extension methods για να προστεθούν νέες μέθοδοι σε κλάσεις, το LINQ και το type inferencing για να δημιουργηθούν οι διάφοροι τύποι από τα αποτελέσματα διαφόρων queries.

---

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

Συμφωνώ με τον κ. Καναβό,  τουλάχιστον στο Link Project δημιουργούν κλάσεις-objects για να κάνουν queries απάνω σε αυτές και έχουν άρθρα του τύπου LINQ Over DataSet for C# Developers, σαν να λέμε ότι η καινούρια τεχνολογία.. αυτή που θα υποστηριχτεί από την Microsoft, θα υποστηρίζει και τα Datasets. Οπότε για projects που θα έχουν την δυνατότητα να χρησιμοποιήσουν το Linq Project ( δηλαδή την C# 3.0 ), και το LINQ τους λύνει όλα τα προβλήματα, δεν βλέπω τον λόγο να χρησιμοποιησούμε Datasets ( και να έχουμε ενδιάμεσες κλάσεις για να κάνουν ερωτήματα με το LINQ ). Ανάλογα το Project { χρόνος υλοποίησης, complexity, team knowledge, maintenance plan } επιλέγεις και την κατάλληλη λύση, δεν είναι απαραίτητα η σωστή επιλογή το α)  ή το β).