Δεν είμαι πολύ καιρό στο χώρο (σχεδόν 2 χρόνια) και τελευταία με απασχολεί πολύ το θέμα της αρχιτεκτονικής. Διάβασα αρκετά τόσο σε msdn (patterns,designs) καθώς και σε άλλα sites για τα layers και όλα τα σχετικά με αυτά. Το πρόβλημά μου όμως παραμένει καθώς δεν έχω δει ένα υλοποιημένο ένα project με αυτό τον τρόπο (σίγουρος πως είναι και ο σωστός βέβαια). Το ξέρω πως ζητάω ίσως πολλά, αλλά μπορεί κάποιος να μου εξηγήσει καλύτερα ή να μου δώσει κατατοπιστικά links? Με ενδιαφέρει ιδαίτερα να δω μια μικρή υλοποίηση (ένα παράδειγμα) για να καταλάβω επακριβώς το θέμα.
Ευχαριστώ προκαταβολικά.

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

---

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

DotSee Web Services

Ας πούμε ότι με ενδιαφέρει να δω μια υλοποίηση user interface - business - data access. Δεν ξέρω αν γίνομαι βέβαια κατανοητός γιατί δεν γνωρίζω και πολλά πάνω στο θέμα. Δεν έχω ξεκαθαρίσει πως ακριβώς γίνεται η επικοινωνία των layers μεταξύ τους. Εντάξει (αν έχω καταλάβει καλά) δεν "μιλάνε" όλα μεταξύ τους (το user "μιλάει" με το business κ.λ.π.) αλλά αυτό γίνεται απλά καλώντας μια κλάση από το άλλο layer? Μπορώ να καλέσω μια κλάση από άλλο layer χωρίς το αντικείμενο που την κάλεσε να ξέρει πια καλεί?
Ελπίζω να γίνομαι κατανοητός.

Πολύ - πολύ γρήγορα να κάνω μια αρχή πάνω σε αυτά που αναφέρεις, λέγοντας οτι η "κλασική" πλέον σχεδίαση περιλαμβάνει 3 layers (ή tiers).

Το πρώτο είναι το presentation, οπου, όπως σωστά μαντεύεις, περιέχει το UI σου.

Το δεύτερο είναι το business (ή middle tier κατά άλλους), το οποίο καλείται συνήθως από το presentation tier. Το presentation δηλαδή μιλάει με business objects, χωρίς να γνωρίζει πως και με ποιό database γινεται η επικοινωνία.

Το τρίτο tier είναι συνήθως το λεγόμενο DAL (data access layer). Σε αυτό μιλάει το business layer και ζητάει data.

Αρα έχουμε μια δομή οπου κάθε layer γνωρίζει μόνο το απο κάτω του.

Αυτή ειναι μια απλή, θεωρητική δομή. Στην πράξη, μπορεί να έχουμε περισσότερα των 3 layers.

---

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

DotSee Web Services

Ωραία ως εδώ. Αν έχω καταλάβει καλά από αυτά που έχω διαβάσει (μου χουν βγει τα μάτια) μπορώ το interface layer να το χωρίσω ακόμα περισσότερο σε (με απλά λόγια) οθόνες και componets που καλούν τις οθόνες και τις διαχειρίζονται κατά κάποιο τρόπο, επειδή απλά μπορεί δύο οθόνες να αναφέρονται στο ίδιο (πχ μια web και μια win οθόνη). Στο business layer έχω κλάσεις που αντιπροσωπεύουν τα entities και καλούν κλάσεις από το data access layer (στις οποίες εκτελώ transactions κ.λ.π). Είμαι οκ ως εδώ?

Γενικά σωστά έχεις καταλάβει. Οσον αφορά το UI layer, δεν το "χωρίζεις" με την έννοια που έχει η λέξη, αλλά απλά μπορείς, έχοντας μια n-tiered εφαρμογή, να "αντικαθιστάς" στο μέτρο του δυνατού τα layers. Ετσι, ιδανικα και θεωρητικα, εφόσον π.χ. έχεις ένα UI το οποίο είναι web-based, και εφόσον αυτό μιλάει σε ένα business logic layer (τα entities όπως αναφέρεις σωστά και εσύ), θα μπορούσες να φτιάξεις ΚΑΙ ένα άλλο UI το οποίο να είναι windows forms - based και να μιλάει με τα ίδια entities.

---

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

DotSee Web Services

Να δώσω και ένα πολύ απλό παράδειγμα αυτού που περιγράφω παραπάνω:

(Μιλάω πάντα για την κλασική προσέγγιση που ανέφερα παραπάνω - υπάρχουν κι άλλες):

Εχω, για παράδειγμα, μια εφαρμογη σε Windows Forms η οποία μιλάει με μια Access Database και ο μοναδικός της σκοπός είναι να μου εμφανίζει την εγγραφή του πελάτη με κωδικό 1001.

Τι θα έκανα για να φτιάξω τα 3 layers που λεμε:

- Presentation: Μια windows form η οποία "μιλάει" στο αμέσως από κάτω layer και του λεει: "Φερε μου ένα customer object που να έχει κωδικό 1001". Οταν το παρει, ξέρει πως να το δείξει.

- Business Logic: Εδώ υλοποιείται το customer object. Για να το γεμίσει, αυτή η κλάση μιλάει με το DAL (data access layer) και του λέει: "Φερε μου από τη database τα πεδία του customer με τον κωδικο που θα σου δώσω", παίρνοντας πίσω "κατι" (ενα dataset, ενα datatable, ένα array, ένα delimited string, ένα xml, κατι τελος παντων από το οποίο θα μπορέσει να αντλήσει τις πληροφορίες και να γεμίσει τον εαυτό του - τα properties του). Το παρόν layer ΔΕΝ ξερει απο databases και ΟΥΤΕ ξέρει ποιός το έχει καλέσει. Η μόνη του δουλειά είναι να μιλάει στο "απο κάτω" layer.

- Data access: Εδώ υλοποιείται η επικονωνία με τη database. Για το παράδειγμά μας, κάπου υλοποιείται μια μέθοδος η οποία τρέχει στην Access ένα query του στυλ "SELECT a,b,c,d,e,f FROM Customer WHERE id=?" οπου στη θέση του ? μπαίνει το ID που θέλουμε και επιστρέφει προς τα πίσω κάτι (dataset, datatable, array....). ΄Το layer αυτό έχει αποκλειστική του ευθύνη την επικοινωνία με τη database και τίποτα άλλο.

Σε τι μας βολεύει αυτό;

- Αν αύριο αντί για Access αποφασίσουμε να χρησιμοποιήσουμε SQL Server, ξαναυλοποιούμε μόνο το DAL.
- Αν αύριο αντί για Forms αποφασίσουμε να χρησιμοποιήσουμε Web, ξαναυλοποιούμε μόνο το presentation.
- Αν αύριο θελήσουμε να προσθέσουμε π.χ. ένα υπολογιζόμενο πεδίο στο object του πελάτη, (π.χ. καθαρές αμοιβές, που δεν υπάρχουν - υποθέτουμε - στη database αλλά μπορούν να υπολογιστούν) - αλλάζουμε το business logic layer, και βλεπουμε αν χρειαστεί να κάνουμε αλλαγές στα υπόλοιπα.

Το ξαναλέω για να είμαι ασφαλής: Αυτά τα παραδείγματα είναι ΠΟΛΥ απλουστευμένα.

 

 

 

 

---

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

DotSee Web Services

Ωραία τώρα να δώσω και τη χαριστική βολή :-) .
Ας πούμε πως έχω μια φόρμα και απεικονίζω για παράδειγμα "πελάτες". Και θέλω να βάλω ένα καινούριο πελάτη.
(τα παρακάτω μπορεί να χουν συντακτικά λάθη τα γράφω κατευθείαν εδώ - η λογική με ενδιαφέρει).
Ας πούμε έχω ένα κουμπί για insert. Στο event κλικ καλώ την insertcustomer(). Αυτή καλεί μια κλάση από το business layer (ας πούμε την clscustomer) καλεί μια ρουτίνα να ελέγξει αν τα πεδία που θα περάσει είναι οκ σαν τιμές και αν αυτή επιστρέψει true καλεί την insertcustomer της κλάσης clscustomer:
Dim mycustomer as new BL.clscustomer (όπου BL το business layer)
If mycustomer.Checkfields(εδώ βάζω τα πεδία) then
try
mycustomer.insertcustomer
catch ex

finally
end try
end if

H κλάση clscustomer με τη σειρά της καλεί μια κλάση στο data access layer και η οποία εκτελεί το insert.

Είμαι καλά ως εδώ?

Με πρόλαβες. Ωραία τα κατάλαβα όλα αυτά.
Μια ρώτηση που ρχεται στο μυαλό. Το DAL έχει πχ μια κλάση για κάθε object του BL και υλοποιεί ένα interface? Ή του περνάω πεδία για παράδειγμα και έχω έτσι μια κλάση μόνο για τα nserts, updates, deletes κ.λ.π.?

Χονδρικά ναι, εισαι καλά. Η myCustomer θα έχει κάτι σαν "insertCustomer" ή ακόμα καλύτερα "Save()" (μια και το DAL δεν ειναι απαραίτητο να μιλάει σε database, μπορεί να μιλάει π.χ. σε flat files).

Επίσης (σε θεωρητική προσέγγιση πάντα) για να κάνεις initialize τον myCustomer θα μπορούσες να ακολουθήσεις και το παρακάτω σκεπτικό:

Dim myCustomer As New BL.clsCustomer (εδώ βάζεις τα πεδία)
If myCustomer.Check() Then ....
...
End If

Οπου η Chech() θα ελέγχει τις΄τιμές των πεδίων.

Το ποιός θα ελέγχει τις τιμές των πεδίων (Business Layer ή Presentation) εξαρτάται από το που εσύ θέλεις να γίνονται οι έλεγχοι. Συνήθως στο BL οι έλεγχοι γίνονται μόνο στο επίπεδο που οι τιμές "ενοχλούν" τη συνέχιση της διαδικασίας (π.χ. τιμές που θα δημιουργήσουν προβλήματα σε περαιτέρω χρήση του object). Το που θα γίνεται ο έλεγχος είναι, κατά την άποψή μου, καθαρή επιλογή του προγραμματιστή.

Προσωπικά ναι, κάνω τον έλεγχο στο business layer όταν πρόκειται για περίπλοκα entities. Παράλληλα, υλοποιώ και κάποιους ελέγχους στο UI απλά για να προειδοποιώ το χρήστη πριν είναι πολύ αργά. :)

---

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

DotSee Web Services

zeon wrote:

Με πρόλαβες. Ωραία τα κατάλαβα όλα αυτά. Μια ρώτηση που ρχεται στο μυαλό. Το DAL έχει πχ μια κλάση για κάθε object του BL και υλοποιεί ένα interface? Ή του περνάω πεδία για παράδειγμα και έχω έτσι μια κλάση μόνο για τα nserts, updates, deletes κ.λ.π.?

Χμμμ...εδώ ερχόμαστε στο φλέγον θέμα των τρόπων επικοινωνίας business/DAL..:)

Επειδή αυτό χρειάζεται αρκετή κουβέντα, υπόσχομαι να επανέλθω με περισσότερες λεπτομέρειες :)

(Γενικά να σου πω οτι υπάρχουν n τρόποι με τους οποίους μπορείς να σχεδιάσεις τι θα κάνει τι....)

 

 

---

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

DotSee Web Services

Ευχαριστώ πολύ. Ξεκαθάρισα πολλά. Περιμένω τις λεπτομέρειες που μου έταξες... :-)

Να γράφεις και άλλα τέτοια! Χρειαζόμαστε τέτοιες συζητήσεις, για κάθε post μας εκτιμώ οτι υπάρχουν αρκετοί άλλοι χρήστες που διαβάζουν και (ισως) λαμβάνουν απαντήσεις σε ερωτήματα που είχαν μέσα στο μυαλό τους (αλλα δεν θελουν ή δεν βρίσκουν τρόπο να τα εκφράσουν σε μια ερώτηση)!

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

---

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

DotSee Web Services

Ρε συ, Σωτήρη, έτσι όπως τα χωρίζεις, γεμίζεις στην ουσία το Business Logic με custom objects. Είναι αυτό business logic;

Στην περίπτωση που δεν δουλεύεις καθόλου με custom objects αλλά το DAL σου γυρνάει πολύ όμορφα typed datasets (με τα οποία μπορεί να δουλέψει μια χαρά το UI) τι έχεις μέσα στο BL;

Όπως απορρέει και από το όνομα αυτού του Layer (business logic) εμένα περισσότερο μου φέρνει ότι έχει κώδικα που ξέρει πως να συνδυάζει, να επεξεργάζεται δεδομένα, ακολουθώντας κάποιο "business logic". Αυτό που περιγράφεις εσύ, μου μοιάζει με ένα δεύτερο DAL το οποίο γεμίζει και τροφοδοτεί τον κόσμο με αντικείμενα = δεδομένα. Άρα στην ουσία έχεις:

1. ADO DAL (μιλάει με τη βάση και επιστρέφει δεδομένα σε κάποια απλοική μορφή)
2. Object DAL (μιλάει με το ADO DAL και μοιράζει στον κόσμο δεδομένα οργανωμένα σε objects) (εδώ ίσως έχεις χώσει και κάποια ελάχιστα ψείγματα business logic που δεν σου δημιουργείται η ανάγκη να τα βάλεις αλλού γιατί είναι ελάχιστα)
3. Presentation Layer (βουτάει objectάκια από το Object DAL και παίζει με τον χρήστη)

Νομίζω ότι αυτό είναι ένα πολύ common λάθος, να μπλέκεις το business logic με άλλα πράγματα επειδή σε πολλές περιπτώσεις είναι ελάχιστο, αν όχι ανύπαρκτο.

Τι να σε πω, από τη δική μου εμπειρία έτσι το έχω δει...

 

---

Χρήστος Γεωργακόπουλος

Εχεις δίκιο. Εβαλα τα data carrier objects στο middle tier, το έκανα όμως για να κρατήσω όσο πιό απλό γινεται το παράδειγμα για το συνάδελφο zeon, για να του δώσω μια "βάση" για την αρχική του ερώτηση.

Επίσης, αποτελεί ένα πολύ μικρό μέρος της απάντησης στην ερώτηση που διατύπωσε ο zeon "πως συνδυάζουμε το BL με το DAL". Μια προσέγγιση είναι οτι το BL (business layer) χρησιμοποιεί data carrier objects τα οποία δεν έχουν δική τους λογική, αλλά τα "γεμίζει" το ίδιο το BL (μεσω manager classes, ισως) καλώντας το DAL. Το ίδιο BL μπορεί να "παίξει" με αυτά τα objects δημιουργώντας έτσι το business logic που απαιτεί η εφαρμογή.

Αυτός είναι όμως ένας από τους τρόπους.

Ενας άλλος τρόπος, όπως σωστά είπες, ειναι να μην έχεις BL (τραβηγμένο αυτό) ή τουλάχιστον το BL να μην ασχολείται με τα data carriers γιατί αυτά μπορούν να είναι πολύ όμορφα typed datasets. Εκεί βαζεις το BL να κάνει άλλα πράγματα όπως π.χ. validate ιεραρχίες από objects ή calculate πράγματα ή δεν ξερω και εγώ τι.

Οσον αφορά τα data carrier objects, μπορούν να ανήκουν στο BL κατά την άποψή μου. Μπορούν να είναι "παχιά" ωστε να αναλαμβάνουν τις CRUD διαδικασίες αυτοτελώς ή "λεπτά" ωστε να υπάρχει κάποια άλλη κλάση (συνήθως την ονομάζω manager) που να αναλαμβάνει τόσο τις διαδικασίες CRUD σε επικοινωνία με το DAL όσο και το να υλοποιεί όποιο άλλο business logic χρειάζεται σε επίπεδο entity.

Τελος, υπάρχουν και τα Ο/R frameworks (βλ. nHibernate) που πρακτικά μιξάρουν DAL και ένα μέρος του BL αφήνοντάς σε να γράψεις ένα άλλο, πιό καθαρό layer που περιέχει αποκλειστικά και μόνο business logic που δεν έχει να κάνει με το integrity των δεδομένων ή ακόμα και με validations σε μεμονωμένα instances.

Το θέμα είναι οτι εδώ δεν επιχείρησα να κάνω μια λεπτομερέστατη ανάλυση του τι ειναι BL και τι DAL, αλλά, όπως είπα και στην αρχή, να δώσω ένα υπερ-απλοικο παραδειγμα ενός 3-tier πράγματος. Τονίζω το "υπέρ". Δεν μπορείς να αρχίσεις από ολοκληρώματα σε κάποιον που σε ρωτάει για κλάσματα, πρέπει να του πεις (με μερικές παραδοχές βεβαια) κάποια πράγματα πρώτα και μετά να τον βάλεις σε πιό δύσκολες έννοιες για να καταλάβει.

---

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

DotSee Web Services