Καλημέρα σας, λοιπόν υπάρχουν πολά ερωτήματα σχετικά με την ανάπτυξη 3-Tier εφαρμογών και επειδή είχα θέσει και εγώ αρκετά αλλά μάλλον δεν ήταν κατανοητά επανέρχομαι με παράδειγμα. Στην εφαρμογή που επισύναψα υπάρχουν 2 φόρμες που επεξεργάζονται τον πίνακα Customers της ΒΔ Northwind. Η 1η είναι με την χρήση Objects (πιστεύω να είναι κατανοήτο τι εννοω Objects) και η 2η χωρίς την χρήση Objects. Τώρα τα ερωτήματα και τα προβλήματα:

1. Στην φόρμα με την χρήση Objects μπορούμε να κάνουμε πολλές αλλαγές πχ στις 5 πρώτες εγγραφές ν’ αλλάξουμε το CompanyName και μετά να τα σώσουμε στην ΒΔ. Γίνετε αυτό οι οι αλλαγές πρεπει να σώζονται μια-μια;

2. Τι λάθος υπάρχει στην 2η φορμα (χωρίς Objects) και δεν σώζονται οι αλλαγές, έστω και μίας εγγραφής; Τι μου ξεφεύγει;

Αυτά προς το παρόν.

Ευχαριστώ

Αυτό που περιγράφεις είναι το Client/Server, όχι το 3-tier. Όταν λέμε 3-tier, εννοούμε ότι υπάρχουν οι clients, server components και η βάση. Μάλλον αντί για tier να εννοείς layer, καθώς στον κώδικα σου βλέπω να υπάρχει ένα project BLL και ένα DAL.

Κοιτάζοντας λίγο παραπάνω τον κώδικα, νομίζω ότι το πρόβλημα είναι ότι δεν έχεις εξοικειωθεί με το data binding και το ADO.NET. Αντί να προσπαθείς να φτιάξεις BLL και DLL και να κάνεις data binding στη φόρμα με τη μία, καλύτερα θα είναι να δεις πρώτα πως δουλεύει το data binding. Δοκίμασε να προσθέσεις ένα Database Datasource στην εφαρμογή σου και κάνε drag&drop ένα πίνακα σε μία καθαρή φόρμα για να δεις τί κώδικας δημιουργείται. Κάνε μετά το ίδιο με object datasource.

Όσον αφορά την πρώτη ερώτηση, αν κατάλαβα καλά ρωτάς αν γίνεται να κάνεις batch update τις αλλαγές σε πολλά αντικείμενα? Έτσι όπως έχεις γράψει τον κώδικα, όχι. Για να γίνει αυτό αντί να λες σε κάθε αντικείμενο "σώσου" θα πρέπει κάπου να περνάς απ' όλα τα αντικείμενα, να μαζεύεις τα update statements και να τα εκτελείς όλα μαζί σε batch. Ολίγον μπελάς να το κάνεις μόνος σου, οπότε θα ήταν καλύτερα να χρησιμοποιήσεις κάποιο ORM όπως το NHibernate, το οποίο ήδη έχει αυτή τη δυνατότητα. Εξοικειώσου όμως πρώτα με το data binding πριν χωθείς σε πιο βαθειά νερά.

Όσον αφορά τη δεύτερη ... δεν προλαβαίνω να τρέξω τον κώδικα. Αλλά δες τον κώδικα που δημιουργείται από το ίδιο το VS για ένα database datasource.

Όσον αφορά το πρώτο μου σχόλιο, όταν μπλέκεις ορολογίες, καταλήγεις να ψάχνεις σε λάθος σημεία είτε στο documentation είτε στο Google και να μην βγάζεις άκρη. Αν έψαχνες για απάντηση στο πρόβλημα σου κοιτώντας άρθρα για 3-tier, δύσκολα θα έβγαζες άκρη. Το πρόβλημα σου μάλιστα έχει να κάνει περισσότερο με data binding και ADO.NET παρά με τον διαχωρισμό της εφαρμογής σε layers.

  Παναγιώτη, πρώτα απ’ όλα σ’ ευχαριστώ για την απάντηση στα ερωτήματά μου. Τώρα όσον αφορά τις απαντήσεις σου:

1. TIER vs LAYER. Αν κάνεις search στο internet θα δεις ότι αυτά τα 2 σήμερα ταυτίζονται. Ισως παλιά να ίσχυε ο διαχωρισμός που κάνεις. Σου παραθέτω την άποψη του P. D. Sheriff η οποία είναι ταυτόσημη με όλων όσων έχω διαβάσει:

When programmers talk about 3-tier, Ν- Tier OR multi-tier architecture they are talking about breaking υρ a program into "services". Α service is a component (a class ΟR set of classes working together) that performs a piece of functionality for an application. Each service can reside οπ one machine, ΟR can be spread across multiple machines. Ιn the most traditional sense, each machine is considered a "tier", however, I like to think of each "service" as a tier.

Most programmers realίze that it may not always be feasible to move these "services" to other machines, but that it is a great idea to separate each "service" into a logical component. This then becomes a logical separation of services. Try not to focus οn a specific number of tiers ΟR services, just break components into logicaI services that fit your appIication, and let that be the deciding factor οr how many "tiers" you end υρ with.

The typical 3-tier approach dictates that you have a user interface, ΟR display service, a business rule service, and a database service. Ι often find this too Iimiting, as there are typically many services that work together at the same tier, as well as from one tier to another.

2. Το πρόβλημα στον κώδικα ήτα οι ελλειπεις παράμετροι του SQLPARAMETER πχ

commandUpdateCustomer.Parameters.Add("@Name", DataType, Size, SourceColumnName)

και όχι commandUpdateCustomer.Parameters.Add("@Name", SourceColumnName)

3. Τί είναι λάθος στο Data Binding; Στα μεν objects είναι με Drag&Drop στο δε άλλο με κώδικα.

Και πάλι σ’ ευχαριστώ.

When programmers talk about 3-tier, Ν- Tier OR multi-tier architecture they are talking about breaking υρ a program into "services". Α service is a component (a class ΟR set of classes working together) that performs a piece of functionality for an application. Each service can reside οπ one machine, ΟR can be spread across multiple machines. Ιn the most traditional sense, each machine is considered a "tier", however, I like to think of each "service" as a tier.

Κάθε service μια κλάση ή ένα σύνολο κλάσεων ...?
Λίγο αυστηρός μου φαίνεται ο ορισμός και προσανατολισμένος στις κλάσεις δηλαδή σε μια Object Oriented προσέγγιση.... πράγμα όχι απαραίτητο.

Η δική μου η αντίληψη περί tier είναι οτι κάθε tier μπορεί να αποτελέσει μια μεμονομένη οντότητα και να λειτουργήσει ανεξάρτητα από τα άλλα tiers. Μπορεί να έχει υλοποιηθεί σαν DLL, σαν Library, σαν function, σαν ένα άλλο πρόγραμμα, σαν service (Windows service - όχι σαν το "service" του... Σερίφη... ) κ.ο.κ.

Αυτό που το οριοθετεί είναι η ανεξαρτησία του από τα άλλα tiers καθώς και η ομοιογένεια των "συστατικών" που το αποτελούν τα οποία συνιστούν μια οντότητα που μπορεί να χρησιμοποιηθεί αυτούσια.

Τελικά.... όσο κι αν προσπάθησα την ακαδημαϊκή προσέγγιση (βλέπε και ξύλινη γλώσσα - ενίοτε) δεν μπόρεσα να την αποφύγω!!!!

Το γνωρίζω ότι γίνεται μεγάλο μπέρδεμα για το τί σημαίνει layer και τί σημαίνει tier, και μάλιστα η Microsoft ευθύνεται σε μεγάλο βαθμό γι αυτό. Πολλά από τα παλαιότερα άρθρα του MSDN χρησιμοποιούσαν τους όρους σαν να είναι ταυτόσημοι. Τα τελευταία χρόνια όμως οι όροι έχουν ξεχωρίσει γιατί η ανάπτυξη layer έχει τελείως διαφορετικές ανάγκες, τεχνικές και best practices από την ανάπτυξη tiers. Μάλιστα, αυτό που είναι σωστό στη μία περίπτωση μπορεί να είναι λάθος στην άλλη. Για παράδειγμα, όταν καλείς ένα service σε άλλο υπολογιστή είναι καλύτερο να κάνεις μία μεγάλη κλήση παρά πολλές μικρές, γιατί το κόστος είναι πολύ μεγάλο. Αντιθέτως, το UI layer συνήθως θέλει να κάνει πολλές μικρές κλήσεις στο business layer.

Αντιγράφω λόγω τεμπελιάς από το άρθρο "Pragmati Architecture: Layering" του Ted Neward :

-------

A layer is a logical separation of software, a basic separation of concerns at the developer level, so we can more easily partition the responsibilities of the system. This is further documented in [POSA1], where the Layers pattern states that using Layers "helps to structure applications that can be decomposed into groups of subtasks in which each group of subtasks is at a particular level of abstraction." In other words, it's classic separation of concerns: split the various tasks involved in an enterprise system—the retrieval of data, the storage of data, the execution of business rules against that data, the display of data, the collection of input, and so on—into components or subsections, so that we can more easily track what is happening where and when. Naturally, the most common division of labor is into presentation, logic, and data-access layers. Note, however, that we're not immediately making any presumption about where each of these layers will run—not yet.

A tier, on the other hand, is a physical layer of hardware, usually a computer of some form, on which some or all of our system can run. Traditional client/server computing—writing a program that executes SQL statements against a database running on a separate server—is a two-tier system. The World Wide Web we all enjoy on a daily basis is also built on the backs of a two-tier approach, where one tier, the client machine, sits in somebody's home or office and remotely accesses a second tier, sitting in a server room somewhere. And so on.

---------

Τα components του κάθε tier μπορούν να έχουν το καθένα το δικό του presentation layer (στον client είναι το UI, στον server είναι η κλάση ή τα web services που εμφανίζει προς τα έξω), business layer και data layer (local cache στον client, η κυρίως βάση στο server), με διαφορετικές όμως αρμοδιότητες. Δεν μπορείς όμως να πεις ότι τα components ενός layer μπορούν να έχουν πολλά tiers. Από την άλλη, η χρήση πολλών layer σε μία εφαρμογή είναι χρήσιμη στις περισσότερες περιπτώσεις. Η χρήση πολλών tiers πολλές φορές πρέπει και μπορεί να αποφευχθεί. Μία single user desktop εφαρμογή μπορεί να έχει UI, business layer και data layer, δεν χρειάζεται όμως ξεχωριστό server.

Ρίξε μία ματιά και στο υπόλοιπο άρθρο καθώς εξηγεί και τους λόγους για τους οποίους επιλέγει ή δεν επιλέγει κανείς μία N-tier αρχιτεκτονική. Αν ενδιαφέρεσαι να ασχοληθείς σοβαρά με N-tier εφαρμογές αξίζει να διαβάσεις το βιβλίο "Patterns of Enterprise Application Architecture" του Martin Fowler, το οποίο καλύπτει θέματα data access, concurrency, business logic, session management κλπ. Θέματα τα οποία είναι εξαιρετικά χρήσιμα όταν φτιάχνεις μία N-tier εφαρμογή.