7

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?

yannis
  • 39,547
  • 40
  • 183
  • 216
Rafael
  • 687
  • 1
  • 8
  • 16
  • 1
    n-layer architecture as opposed to? The alternative is impossible to qualify. – MattDavey Jan 06 '12 at 14:34
  • 12
    the benefits you describe are pretty big benefits by themselves. – nwahmaet Jan 06 '12 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). – P.Brian.Mackey Jan 06 '12 at 15:36
  • @MattDavey wrt _alternative to n-tier architecture_ as far as I know one that qualifies is **[monolithic](http://en.wikipedia.org/wiki/Monolithic_system)** – gnat Jan 06 '12 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 06 '12 at 16:48
  • If you are database agnostic but never switch databases all efforts in this regard are wasted. Estimate the probability that you will *ever* want to switch databases. Also compare this with simply making a port in a VCS branch at the time you want to switch databases. There is a difference between being able to switch at runtime vs. switching by porting. – usr Feb 26 '15 at 15:10

4 Answers4

12

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.

Charles Lambert
  • 2,019
  • 17
  • 18
10

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.

Oded
  • 53,326
  • 19
  • 166
  • 181
  • `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 06 '12 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 06 '12 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. – Wyatt Barnett Jan 06 '12 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 06 '12 at 16:00
  • I would add an important point to the list: **Testing**! If Your BL is separate, then you can make unit tests for your logic. How would you do that, if the logic was inside a button click event handler? – Olivier Jacot-Descombes Jan 06 '12 at 16:01
  • 1
    @OlivierJacot-Descombes - Already done ;) – Oded Jan 06 '12 at 16:01
  • Whether DB scaling requires code changes depends on the DB architecture. Most of the time you can set up failovers or even clusters with only conn string changes; most DBMSes are designed to look like one entity to users regardless of their physical organization. – KeithS Jan 06 '12 at 16:09
5

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.

jfrankcarr
  • 5,082
  • 2
  • 19
  • 25
  • 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 06 '12 at 16:28
3

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.

Paul T Davies
  • 3,144
  • 2
  • 22
  • 22