Benefits of using three tier arhitecture

I understand the benefits of three tier architecture ( for example, changing code in one layer doesn’t usually affect code in other two layers ), but I don’t understand why it would be bad idea for UI layer to ( in certain circumstances ) directly access the `data layer.

a) I can think of few reasons why UI should only talk to BLL layer:

• this way UI developer doesn’t need to know details of DB schema, since BLL layer abstracts DB tables using custom objects.

• also, often times BLL layer processes/validates the incoming data before passing it through to another layer

Are there any other reasons?

b) But i开发者_如何学Gof same developer is writing all three tiers, then are there really any reasons why UI layer shouldn’t directly access data layer (in cases where it doesn’t need the BLL layer to process/validate data)?

thank you

As a database and server developer, I have a simple answer: you can no longer look in one place to see all of the database access, and database changes will now affect more than one module.

If you leave the layers uncoupled you can switch out components like the database engine without recoding your UI layer. Likewise even if the middle layer doesn't have to process / validate data it can be used to retrieve additional data from other sources (other databases, network resources etc) without recoding your UI layer.

It's just a good practice to keep with. It allows you to alter your system to scale or adjust with minimal impact on the other pieces.

Some applications are small enough that a n-tiered architecture is overkill. When you start working with larger applications (remember small application tend to grow into big applications) then it becomes important to:

• Minimize the impact of change
• Test your code

Most important is the ability to test your code without requiring a connection to a database thereby allowing you to truly isolate the object under test.

As for minimizing the impact of change, as your requirements change, your design will likely change. If logic and data access is scattered across your application, then small changes introduce significant risk (and additional testing effort).

Now if you're a one man shop and don't expect your software to grow in any significant way, then there's little need to prepare for it with a more complex design.

On the other hand, they're called "best practices" for a reason.

Security. The BLL should be accessible from the client, and only exposes the methods you want people on the client to use. How do you securely store the database connection string in the Client code?

Depending on the language and framework you use you can make the BLL methods only accept pre-authenticated calls.

I am assuming the UI is Client Application and not a website.

In the end this type of decision comes down to preference (obviously), but it is also a reminder that every architectural decision needs to be traceable to a certain purpose. Those purposes or requirements can have a multitude of backgrounds, ranging from business to technical, but the important point is that they should be there, for the simple reason that whenever you find yourself questioning specific details (decisions) in the architecture at hand, you can trace the motivation behind the decisions.

In doing architectural reviews, I often find a 3-tier UI/BLL/DAL architecture as you described, and very often for no other reason than "everybody else is doing it", "it is the Microsoft way", et cetera ad nauseam. It is a fine architecture (or layer pattern), but it is not the one-size-fits-all (since that doesn't appear to exist in IT anywhere).

A few questions that come to mind: where do the custom objects live that "abstract the DB tables" (quote), and to what level do you expose these? Are these DTOs, or objects from the BLL that are populated by the DAL? Does the UI know these objects (direct reference), or are they hidden by the BLL? Are objects in the BLL persistence-aware? What do your references between tiers look like? Drawing a high-level picture can help here.

Some reasons not to do what you propose have already been posted; while these are all valid, each objection can potentially be mitigated by a workaround (or 10). Given a greenfield situation, I actually prefer doing something along these lines, making the data access as (architecturally) lean as possible. I find that this keeps the solution agile and well suited to change when requirements shift (as they always do).

A few suggestions: if you are going to go forward with this, try to explicitly separate reads from writes (queries from commands, questions from transactions, choose your lingo). An alternative to linking the UI to the DAL would be to create a very thing Service layer (how's that for an ambiguous term? Actually, this is why I sometimes name this the "Operations" layer, for no other reason than to disambiguate) that can either grab the required objects directly from your data access layer, or invoke the business layer whenever the operation requires it. This way, you still define all your interaction between the UI and the underlying infrastructure in one way, but you can optimize each operation individually.