Φίλοι developers,

 

Πρόσφατα είχα μια συζήτηση με έναν συνάδελφο περί 3 tier αρχιτεκτονική σε web development.

 

Όλοι γνωρίζουμε ότι τα RDBMS εδώ και καιρό μας παρέχουν την δυνατότητα να μεταφέρουμε business logic στο data tier. Το ερώτημα ήταν (και ακόμα είναι) εάν αυτό είναι καλό η κακό ή εάν δεν θα έπρεπε να μα απασχολεί και πολύ.

 

Μέσα από αυτήν την συζήτηση προέκυψε ένα άλλο ερώτημα πιο primitive.

 

Τι είναι Business logic ή τι δεν είναι business logic;

 

Η δική σας άποψη;

 

 

---

Jason Kataropoulos

Απαπαπα, τι έθιξες μέσα στο καλοκαίρι τώρα..

Δεν θα απαντήσω τώρα γιατι δεν έχω χρόνο, αλλά χωράει μεγάααλη συζήτηση το πράγμα..

---

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

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

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

Η N-tier αρχιτεκτονική έχει τον λογικό σχεδιασμό και τον φυσικό σχεδιασμό. Ενίοτε συγχέονται οι δύο. Πχ το να βάλεις σε ένα stored procedure κώδικα για business logic δεν σημαίνει ότι καταργείς το business logic. Μπορείς να έχεις ένα set από stored procedures οι οποίες να αποτελούν το business logic σου, ωστόσο θα φιλοξενούνται στο RDBMS. Αντίστοιχα, αν μετατρέξεις αυτά τα stored procedures σε classes που θα συνυπάρχουν με τον client (σε DLL δηλαδή), τότε το business logic σου θα φιλοξενείται στον client. Αν τέλος, ορίσεις έναν server στον οποίον θα υπάρχουν αυτά τα dll και θα καλούνται remotely από τους clients και αυτά με τη σειρά τους θα καλούν το RDBMS, τότε θα έχεις πετύχει μια αναλογία ένα προς ένα του φυσικού σχεδιασμού με τον λογικό σχεδιασμό (3-tier).

Για κάθε σχεδιασμό, υπάρχουν πλεονεκτήματα και μειονεκτήμα όπως η πολυπλοκότητα, η ευκολία συντήρισης, το κόστος αλλά πάνω απ'όλα το scalability (πάντα το ξεχνάω στα Ελληνικά, περιφραστικά η δυνατότητα της εφαρμογής να ανταπεξέλθει μελλοντικά σε μεγαλύτερο φόρτο χωρίς να χρειάζεται re-engineering) είναι μερικά από αυτά.

---

Vir prudens non contra ventum mingit

KelMan wrote:

scalability (πάντα το ξεχνάω στα Ελληνικά, περιφραστικά η δυνατότητα της εφαρμογής να ανταπεξέλθει μελλοντικά σε μεγαλύτερο φόρτο χωρίς να χρειάζεται re-engineering) είναι μερικά από αυτά.

Νομίζω ότι μπορείς να το μεταφράσεις ως "κλιμάκωση"

---

Φιλάρετος Σεβαστιάδης.

Albert Camus: Life is the sum of your choices.

Μάλιστα,

Οπότε ρωτάω εγώ:

Είναι κλασική μέθοδος το να γίνεται το paging (σε μεγάλα recordsets) στην stored procedure, είτε με temp tables είτε με διπλά και αντίστροφα sortings κλπ. Στην ουσία αυτό είναι ένα select αλλά περιέχει και business logic.

Αυτό τι είναι λοιπόν;

Γενικότερα έχω αρχίσει να πιστεύω ότι η Ν-Tier αρχιτεκτονική είναι λίγο ουτοπική. Στην πράξη κάποια πράγματα συμφέρει να τα μπερδέψεις στα tiers για λόγους ποικίλους. Αυτομάτως καταρρέει η ιδέα της N-Tier αρχιτεκτονικής. Προσωπικά αυτό μου λεει απλά να μη δίνω και τόση σημασία σε αυτήν την ορολογία που πιστεύω ότι εξυπηρετεί περισσότερο εμπορικού σκοπούς!

---

Jason Kataropoulos

Είναι κλασική όταν το site σου θα εξυπηρετεί μερικούς εκατοντάδες χρήστες την ημέρα. Για το Amazon (το scalability που λέγαμε) είναι συνταγή για την καταστροφή.

Για το paging, ρίξε μια ματιά σε αυτά τα links

http://weblogs.asp.net/scottgu/archive/2006/01/01/434314.aspx

http://dotnetjunkies.com/QuickStartv20/aspnet/doc/data/objects.aspx#bll

Πάντως επαναλαμβάνω, άλλο πράγμα η φυσική σχεδίαση και άλλο πράγμα η λογική σχεδίαση. Το ότι το RDBMS περιέχει BL functionality δεν σημαίνει ότι καταρρέει η multi-tier αρχιτεκτονική.

---

Vir prudens non contra ventum mingit

Business logic είναι αυτό που λέει το όνομά του. Κανονισμοί, περιορισμοί και μέθοδοι στην δομή και στις διαδικασίες που αφορούν τα αντικείμενά σου και στις λειτουργίες που γίνονται σε αυτά.

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

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

Η δυσκολία στο να αντιληφθεί κάποιος τι περιέχει το business layer, είναι ότι σε πολλές περιπτώσεις το business logic είναι τόσο μικρό σε έκταση ή τόσο απλοϊκό, που είναι δύσκολο να εντοπιστεί (Στο παραπάνω παράδειγμα θα μπορούσε να υλοποιηθεί με ένα απλό if then throw exception σε οποιοδήποτε layer, χωρίς να περάσει καν από το μυαλό του developer n-tier κατάσταση). Σε τέτοιες καταστάσεις, ναι, θα μπορούσε να ενσωματωθεί σε κάποιο άλλο layer, αλλά τελικά νομίζω ότι είναι θέμα εμπειρίας το να μπορείς να βλέπεις που έχει business logic το οποίο μπορεί να βγει σε ξεχωριστό layer και που όχι.

Η n-tier αρχιτεκτονική δεν είναι καθόλου ουτοπική και δεν εξυπηρετεί εμπορικούς σκοπούς. Προέρχεται από την τεράστια ανάγκη οργάνωσης μεγαλύτερων projects. Σίγουρα αν μπλέξεις κι εσύ με πολύ μεγάλα projects, με εκατομμύρια γραμμών κώδικα και εκατοντάδες πίνακες και φόρμες, θα νιώσεις κι εσύ πόσο απαραίτητη είναι. Αν πάλι αποκτήσεις την εμπειρία αυτή, θα μπορέσεις να αντιληφθείς καλύτερα τα οφέλη από την εφαρμογή της και σε μικρότερα projects.

---

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

Master Yoda wrote:

Γενικότερα έχω αρχίσει να πιστεύω ότι η Ν-Tier αρχιτεκτονική είναι λίγο ουτοπική. Στην πράξη κάποια πράγματα συμφέρει να τα μπερδέψεις στα tiers για λόγους ποικίλους. Αυτομάτως καταρρέει η ιδέα της N-Tier αρχιτεκτονικής. Προσωπικά αυτό μου λεει απλά να μη δίνω και τόση σημασία σε αυτήν την ορολογία που πιστεύω ότι εξυπηρετεί περισσότερο εμπορικού σκοπούς!

Η n-tier αρχιτεκτονική, όπως και τόσα άλλα πράγματα στην πληροφορική, δεν αποτελούν πανάκεια ούτε το "χρυσό χάπι" για όλες τις περιπτώσεις. Ειναι όμως μια δοκιμασμένη αρχιτεκτονική για projects που ποικίλλουν από μικρά ως τεράστια, και σκοπό της έχει να διαχωρίσει τα διάφορα layers της εφαρμογής ωστε να κάνει τη σχεδίαση, τη συντήρηση και την επέκτασή της ευκολότερες. Σίγουρα για να κάνεις κάτι ευκολότερο θα πρέπει αρχικά να το σχεδιάσεις λίγο πιό περίπλοκα από τη βασική προσέγγιση (code now, think later). Ομως, δεν υπάρχουν 100% σαφείς προδιαγραφές για μια  n-tier αρχιτεκτονική. Ητοι, όπως και στα design patterns, δεν είσαι αναγκασμένος να υλοποιήσεις στο 100% αυτό που ορίζεται από μια προτεινόμενη προδιαγραφή ή από ένα best practice, αλλά καλείσαι να το προσαρμόσεις στις ανάγκες της εκάστοτε εφαρμογής. Ναι, αλλού μπορεί να μεταφέρεις ένα μέρος του business logic στο data tier και αλλού όχι. Αλλού ενδέχεται να μην έχεις καν business logic layer, αν και τελικά μετά από πολλά διαπιστώνει κανείς οτι ακόμα και στις μικρότερες εφαρμογές ορισμένες φορές σχεδιαστικά συμφέρει, παρ'όλο που στην αρχή φαίνεται too much.

Τον τελευταίο καιρό κατασκεύαζα μια μικρή win32 εφαρμογή δημιουργίας προσφορών για μια συγκεκριμένη οικογενεια προϊόντων. Ξεκίνησα φτιάχνοντας μια monolithic εφαρμογή (ολα σε ένα), ωσπου διαπίστωσα οτι η διαδικασία υπολογισμού των τιμών ήταν εξαιρετικά περίπλοκη (attribute-based), και πλήρωσα το λάθος μου αυτό "σκοτώνοντας" όλο τον κώδικα που είχα φτιάξει και ξαναφτιάχνοντας την εφαρμογή ως 3-tiered από την αρχή. Πραγματικά, η απόσβεση που είχα ήταν τεράστια, μια και ο πελάτης διόρθωσε στην πορεία ορισμένα κομμάτια των προδιαγραφών διαφοροποιώντας λίγο τα αρχικά ζητούμενα, αλλά και ζήτησε επεκτάσεις οι οποίες θα ήταν αδύνατο να γίνουν σε μια 1-tier εφαρμογή χωρίς ο προγραμματιστής να καταναλώσει ικανή ποσότητα ηρεμιστικών.

Επειδή βρίσκομαι σε διακοπές και γράφω από  internet cafe,  επιφυλάσσομαι να γράψω περισσότερα όταν γυρίσω στην Αθήνα.

 

---

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

DotSee Web Services

Ακυρο το προηγούμενο - από σφάλμα δικό μου δεν είδα όλο το thread αλλά μόνο το συγκεκριμένο μήνυμα. Πρέπει να κόψω το ποτό. :)

 

---

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

DotSee Web Services

Έστω οτι έχουμε φτιάξει ένα WMS (Warehouse Management System) - κοινώς ένα Πρόγραμμα Διαχείρησης Αποθήκης και το εχουμε εγκαταστήσει σε 2 αποθήκες:

Την Α και την Β.

Η αποθήκη Α συλλέγει προιόντα για να τα αποστείλει στους πελάτες ανά παραγγελία.

Η αποθήκη Β συλλέγει προιόντα για να τα αποστείλει στους πελάτες συγκεντρωτικά (αθροίζοντας όλες τις παραγγελίες ανά προιόν).

Οι 2 παραπάνω κανόνες αφορούν στο Business Logic. To αν αυτό θα υλοποιηθεί σε ένα ξεχωριστό layer ή όχι έχει να κάνει με τον τρόπο που θέλουμε να υλοποιήσουμε το μοντέλο μας και όχι με την ταυτότητα αυτή καθαυτή του business logic το οποίο όπως και να το κάνουμε θα παραμείνει το.... ίδιο. 

---

Nothing to declare...