Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.

share|improve this question
6  
There's no such thing as "always" in software development. –  Robert Harvey Aug 2 '12 at 22:28
1  
An what's your alternative? –  m3th0dman Aug 3 '12 at 9:16
    
@m3th0dman - To separate my classes to components (cs files) lying in the same project, instead of creating 3 different projects in same solution that would communicate with each other. –  BornToCode Aug 3 '12 at 10:12
    
You do not have to create 3 different projects; you can have one project with three big packages - you will still have 3 layer model. –  m3th0dman Aug 3 '12 at 10:50
    
@m3th0dman I also had an idea to skip the BL layer at all because there isn't much processing of data in this app, more inserting inputs to db and generate reports from the db data? –  BornToCode Aug 3 '12 at 12:11
add comment

6 Answers

up vote 1 down vote accepted

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.

share|improve this answer
    
I tend to accept your approach, but from some reason I see @Aadaam answer is the most upvoted even though it made an impression of somewhat unconventional to me, so does it mean people here support in not worshipping the layers design? My intention wasn't to open a philosophical discussion or rebelling against the system (maybe I'll do it when I get more experienced :-) ) but to get a practical advice how should one build his projects in the 'real world', could you please help me get a conclusion from this debate? Should I ignore the upvoting? Thank you! –  BornToCode Aug 5 '12 at 1:22
add comment

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?
share|improve this answer
1  
Actually I had a tiny voice deep inside saying that in case of changes I WILL have to change ALL layers and you just confirmed it. So if it is harder maintenance and more complex code why is it so 'in'? what benefits are left? Would you advice forgetting about this layers idea and divide my classes to dll's lying in the same project? –  BornToCode Aug 2 '12 at 23:41
    
Well, nowadays I do more UX than coding as I just simply don't want to enter in such debates - so much religion, so few facts to support each side, and it just so much doesn't matter to the user, as it's underneath the interface anyway... I believe, that a system should be modeled as a kind of "virtual world", though. I believe there is an inherent beauty in having a virtual model of cogs (to which DDD is the key) and just having a window and a joystick to it, like it was in the original MVC - read my take on MVC here –  Aadaam Aug 2 '12 at 23:54
    
+1 for actually looking at commit history to see what actually changed. However, I seem to recall people arguing that business logic should be separate because it changed the least. Also, I'm not sure how you can argue that the problem is both that changes ripple through all 3 layers and that the BL doesn't really change. –  psr Aug 3 '12 at 0:05
    
@psr: sorry, I didn't say BL doesn't change, I said BL changes slooowly. It's about half of the speed of how fast model changes, it was even about a third in one of the systems I looked at. And it brought to me to a question wether we should have a different take on things, but I haven't gotten anything useful yet, as you know, this is not something which shows up in small throw-away projects, but also not something you want to try out in the usual million-dollar enterprise IT projects :) –  Aadaam Aug 3 '12 at 0:10
add comment

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.

share|improve this answer
    
I think a person who is reading a book about 3-layered architecture (quite a basic phenomenon) is not the person who has enough experience to think through how extensible the model is. But perhaps the best way to gain this experience is to let him/her fail with it - just make sure that both approaches are tried out in two similar projects. –  Aadaam Aug 2 '12 at 23:11
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
2  
This is all true for 3 tier architecture. However the original question was about 3 layer architecture. Tiers are more about physical separation and layers about logical. An application could have 3 layer architecture, even if was only one tier (pure desktop app for example). –  simoraman Aug 3 '12 at 3:22
    
@simoraman, original question is saying "When to use the 3 layers model?" –  Yusubov Aug 3 '12 at 8:40
3  
Yes, the question is about layers, but you talk about tiers. Layers != Tiers. Your answer has good points about tiered architecture but it seems off topic. –  simoraman Aug 3 '12 at 8:46
    
@simoraman +1! One of the biggest misconceptions is that layers and tiers are the same thing - they are not –  MattDavey Aug 3 '12 at 10:06
    
i have made corrections, thanks for catch :) –  Yusubov Aug 3 '12 at 10:09
add comment

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.

share|improve this answer
    
Thank you, but if there's a slight chance that I'll need a BL layer later isn't it a better idea to add it in the first place rather then refactoring it later? –  BornToCode Aug 3 '12 at 12:01
    
@BornToCode: That depends on your development model. If you stick to "waterfall", then what you saying might be better. I favor an agile approach, where adding new features and constantly improving code quality by refactoring goes hand-in-hand. So I try not to introduce anything into my code as long as there is no need for it. But beware - you should not miss the point where a BL or further layers make sense. –  Doc Brown Aug 3 '12 at 12:47
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.