When to use the 3 layers model?

Question

I was recently exposed to the three layer model (DAL,BL,UI). Someone told me I should ALWAYS work with this model.

I have a medium project that I'm starting and I have doubts whether I should build it with layers and make myself work with more complex code just to 'code by the book'?

Even though I read about this model, I'm still not entirely convinced it's worth it. I understood that it would help if I change the UI, but I really don't see any chances that the UI of this app will ever change. So is it worth the hassle?

I would appreciate your opinion - would you advice me to always build projects by this model (even if currently I can't see much of a benefit)?

EDIT: guys, please don't catch me on the word 'ALWAYS' - the meaning was just that generally this is the proper way I should design my projects by.

Answer 1

The three-tier model is well-suited for business applications, of the transactional variety (i.e. multiple user accessing a database). For other types of applications, such as games, highly interactive user interfaces or other real-time data processing, I wouldn't necessarily reach for a multi-tier model, however. So it depends on the nature of the application.

If you compare three-tier to something like Winforms, you will find that, while the three-tier model initially seems more complex at first glance, it will scale much more readily to large projects. The resulting organizational structure will look simple to the trained eye.

Winforms, on the other hand, is much more susceptible to creating a Big Ball of Mud, even though it initially seems like a simpler model. The resulting large project becomes very difficult to manage (without enforcing extreme self-discipline), and will turn out to be far more complex overall.

The same is true of ASP.NET Web Forms vs. ASP.NET MVC.

Answer 2

While it is true, that the standard enterprise architecture is pretty close to the three-layer model, truth to be said, it actually means harder maintenance.

If you grab an SVN/CVS/git/... log of an enterprise application with considerable history, you'll find out, that the rate of change is as follows:

• views change all the time
• models change about as much (or half the rate) as views
• BL rarely changes

That's because corporate processes (formalized or informalized) are dependent on corporate culture, which changes on a much slower rate than data fields.

When 3-layer was popularized, it was said that BL changes most of the time, but I couldn't find support for this in SVN logs of the systems I analyzed this way, it was rather mostly UI change, and model change.

Also, UI changes can also be explained simply that this is where requests are made: it is the user interface,this is what users see, this is where they ask for changes - "can I have another field?" "could I have a new button here?" This is what their vocabulary is based on.

And of course, most of these will affect the underlying persistent model, as it's really rare that a business functionality change doesn't involve database change.

And, to top all of this, usually medium-sized changes echo through all the system, involving all three layers,meaning you edit three files: the UI, the model, and the business logic files of the same module...

It can be that right underneath this post, a swarm of comments will follow with developers who claim that I'm mistaken. Please, in order to have open data (I'm not part of any of these projects now sadly), grab your logfiles, and give us a list of changes:

• how many times did the template / view files change? (% of all, or % of all three)
• how many times did the domain logic (either in controller, or business operation layer) change? (again, % of all or all three)
• how many times did the data model change? (XMLs or model files, dependent on architecture) (again, % of...)
• how old is your 3-layered system in years?

Answer 3

The fact that your book says you should always code in that model is a red flag that it is not a good book.

Different situations call for different paradigms and design patterns. If you feel that that pattern would fit, go ahead and use it. Otherwise, go with what you're comfortable with.

However, don't get caught in the trap of thinking well it won't be useful now. Actually think it through and figure out how extensible the model is, and how well it would mesh with future maintenance, debugging, refactoring, and tweaking.

Answer 4

The "Someone" who told you always to use 3 tier probably has a background in corporate business apps.

• Large 3 Tier projects can fit well to development with a team of specialists, i.e. where devs can be assigned to just one of the tiers - e.g. UI gurus on the presentation tier, strong SQL or DB skills in the data tier, etc.
• 3 Tier is also pretty easy to adapt to SOA - pertinent BL functionality can be wrapped, secured and exposed via a services layer / coupled into an ESB, etc.

That said, we are tending more toward an Onion style architecture, especially in smaller projects with no need for ESB integration etc.

Answer 5

I think it is useful to refresh our understanding of 3 Tier/Layer Architecture Design Components, before starting to design the application. There are some considerations when to choose a 3 tier application architecture. What are they?

• Scalability—Each tier can scale horizontally. For example, you can load-balance the Presentation tier among 3 servers to satisfy more Web requests without adding servers to the Application and Data tiers.

• Performance—Because the Presentation tier can cache requests, network utilization is minimized, and the load is reduced on the Application and Data tiers. If needed, you can load-balance any tier.

• Availability—If the Application tier server is down and caching is sufficient, the Presentation tier can process Web requests using the cache.

There is a grate article for reference in CodeProject that may find helpful to look: Three Layer Architecture in C# .NET. It essentially covers the typical three layer architecture in C# .NET. It is a very useful approach for coding due to easy code maintenance.

Edit: If we looked at tiers like being layers of a cake; each layer would have it's own ingredients and do it's own things. The tiers of each application interact with only the tier above it, or below it.

3-tier means the cake has 3 layers. Usually it's data at the bottom, then an application logic tier (PHP/ruby/etc), and then a presentation tier at the top (html)

If mentioned things above are very essential to consider in your project then you are on a righ track. Otherwise, for a simple non-business application you would essentially skip complexity of 3-Tier Architecture.

Answer 6

Actually, if creating layers makes your application more complex, you do it wrong. Layers shall help you to separate different concerns, to keep your code clean, well-structured, maintainable, and (what is most important) evolvable - that means, it keeps your code in a state where you still can easily add more features, even when your code base enlarges.

Often the alternative means "start with some UI and put all code there", resulting in a big, fat unmaintainable code blurr after a few weeks.

"DAL,BL,UI" is a typical starting point for building layers in a business application. Personally I feel that 3 layers are to many to start with (often "UI" and "DAL" will suffice your needs at the beginning, sometimes "UI" will be enough), but as soon as your application size increases, you come to a point where you should refactor out "BL" logic to a separate layer, or create even more than 3 layers. But that should happen because you see and understand the reason for that in your application, not just because some kind of book tells you that.