I was building an application in .Net for almost a year (almost alone), I took the decision to build it with a 3-layer design. Recently when finished the project, I analyzed if the effort of creating this application with layer design in mind really compensate for the "benefits" obtained implementing such design.

Out of port the desktop application to web without any major code rewrite and to be almost database-agnostic; I don't see any further benefits of this.

Any experiences, and thoughts?

  • 1
    n-layer architecture as opposed to? The alternative is impossible to qualify.
    – MattDavey
    Jan 6, 2012 at 14:34
  • 12
    the benefits you describe are pretty big benefits by themselves.
    – nwahmaet
    Jan 6, 2012 at 14:34
  • If your goal is to extend the useable lifetime of your code, then it's well worth the effort. If you simply want to pump out a product and don't care about it's maintainability...then the benefits are mute. And anyone who has to pickup your code for maintenance is going to curse a flat, highly coupled design (or what I would call a prototype taken to production). Jan 6, 2012 at 15:36
  • @MattDavey wrt alternative to n-tier architecture as far as I know one that qualifies is monolithic
    – gnat
    Jan 6, 2012 at 16:43
  • @gnat true, but the term monolithic doesn't give us any clues on how to characterize, or attribute any qualities to the nature of the monolithic system; so it's still impossible to make a comparison of benefits.
    – MattDavey
    Jan 6, 2012 at 16:48

4 Answers 4


If you have just finished your application then you have not seen the benefits of this approach. You will find most of the benefit of doing this as you begin to make changes to the existing application. Think about how easy it will be to move items around in the UI as you change the application. Or how easy it will be to performance tune a specific portion of the data storage functionality without changing any other code. It is the separation of concerns that is important in the n-tier architecture. You will learn a lot from this experience only if you continue to maintain the code base. Everyone always uses the examples of "write a new UI", or "swap out the database examples". Theses cases are rare, if at all. What does happen is that you will need to add new features or modify existing ones. That is when you will reap the benefits of having your concerns separated into different layers.

With that having been said. An inappropriately written n-tier application can be just as difficult to maintain as an ad-hoc version. The key point of n-tier is separation of concerns. You have to look at every method you write, and ask yourself: How easy will it be to change this existing functionality without affecting other parts of the application? This is the reasoning behind both n-tier and SaaS development. They are just two different versions of the same thing: separation of concerns.


If your application does indeed have these separate layers (I am assuming UI, BLL and DAL), then:

  • You can write other UIs (desktop, mobile) without changes to other layers
  • You can make changes to your BLL and not effect the UI or DAL (and with several different UIs the changes will just happen automatically)
  • You can migrate to a different data store without the need to change the UI or BLL (so, sharding, NOSQL and clustering can be options)
  • Testing each layer in isolation is much easier

When you have such separation, you can also scale the different layers separately (need more power to the UI bit? You can add a web server to the farm. Need more DB power? Shard, cluster or whatever else makes sense, though normally such a change will require changing the architecture).

Of course, if you have developed a site that doesn't need this scale and will not needs to be changes in the above ways, then such an architecture can be over engineering.

  • if you have developed a site that doesn't need this scale and will not needs to be changes in the above ways, then such an architecture can be over engineering You can never say with 100% certainty that some particular aspect will never change or that it will never need to scale.
    – maple_shaft
    Jan 6, 2012 at 14:43
  • 2
    Good points, but I would like to add that seperation of layers allows for easier test driven development and easier ability to unit test your code.
    – maple_shaft
    Jan 6, 2012 at 14:44
  • Good points, but I think that it is far overstating the case that you can scale the data layer easily -- in most cases that is a major rewrite as it tends to change the way the application thinks. Jan 6, 2012 at 14:48
  • 1
    @maple_shaft - I think that for certain types of site, you can. Completely depends on the target audience. As for testing - good point, added to answer.
    – Oded
    Jan 6, 2012 at 16:00
  • 1
    @OlivierJacot-Descombes - Already done ;)
    – Oded
    Jan 6, 2012 at 16:01

Layers for the sake of having layers is a common problem. I've seen a number of services and applications that were technically n-tier but were very guilty of violating principles like DRY, separation of concerns and the like. For example, I've worked with apps that had upwards of 10 object creation steps between the UI and the DB, 30+ different DLLs with redundant functionality and so forth.

Now, there is a huge advantage if you can successfully separate concerns and avoid redundant, dependent and convoluted code. It makes the program easier to test, enhance and maintain. It would be nice if this was done more often rather than 'cargo cult' n-tier layers.

  • I like that term "cargo-cult n-tier layers". I think that comes about when architects fail to truly understand the benefits of n-tier architecture.
    – maple_shaft
    Jan 6, 2012 at 16:28

Databases get superceeded and vendors stop supporting old versions. UI's beccome out of date (it's very hard to support older version of ASP/ASP.net). There are new requirements for UI's these days with the advent of smart phones. If you need to replace either of these, you don't want to replace all the business logic. The business logic is the element that is likely to endure the longest (just think of 30 year old Cobol applications that are still running!). You may also at some point want to service orientate the application, and this will be easier if you can access the business logic directly.

Also, layering makes it much more maintainable and scalable, but also it makes it much more logically structured and readable. You know exactly where everthing needs to go, and when you come back to it, you know where it is. For example, I have worked on many 'forms over stored procedure' applications (This being a common alternative to an n-layered application) and I find the business logic strewn between the UI and the stored procedures. If there is a BLL, there is no excuse for it to be anywhere else other than the BLL (OK, except in very exceptional circumstances).

Also, I dispute the fact that an n-layered application really requires that much more effort to develop? I certainly think the development overhead is massively paid off by the maintainability.

Not all application warrant an n-layer architecture but I would imagine anything that took a year to develop would.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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