Geek Smithology

October 7, 2005

N-Tiered sucks for high values of N

Filed under: Craft of Dev by Nathan @ 12:58 pm

Read this post over on the code monkey blog, and it reminded me of a conversation I had with the mayor of fuchietown. Code Monkey says the following:

Following a framework like this (tiered or layered — ed.) makes applications much easier to develop and support. Every object has it’s place and is easier to reuse. This also allows for easily adopting to new technologies. Since each tier does not know the implementation of the other, changing that implementation will only effect the tier being changed.

Now, I don’t want to sound like I’m spanking the code monkey here, because in some circles this is considered common wisdom. But there are trade offs that you have to consider.

Are these apps easier to develop? Sometimes. Are they easier to support? Naw.

Tiering is great for horizontal concerns (i.e. replacing your Oracle DAO implementation with a PostgreSQL DAO implementation), but a pain in the ass for vertical concerns. For example, let’s say that something in our controller needs to be modified to take another parameter into account. We’re agile, and as such didn’t think of every single parameter that we might want to pass, so we have to code it from scratch.

I have to modify the data interface, the data implementation, the business implementation, possibly the business interface, and the presentation, which could consist of multiple files. Add a BusinessDelegate to the mix and I could be editing more than 8 files just to add a parameter.

Not knocking the teired approach – I’ve used it, and if it’s done properly it works. But for the love of #{deity} don’t charge into every single project with your J2EE design patterns book and your 3 tiers or bust t-shirt, because there is no one true path of web application architecture.

Consider the problem, consider the alternatives, weigh the tradeoffs.

2 responses to “N-Tiered sucks for high values of N”

  1. Code Monkey says:

    Yes, this case os true. Having to add a parameter in every tier is a pain. Or having to add an entirely new method is too. But I tend to prefer this over a system that will have jdbc code in the JSP or batch clients calling DAO classes (both of which I have seen). To avoid the issue you have mentioned I’ve started using Hiobernates query by example methods and I find that covers 95% of those issues.

  2. Do you mean Hibernate? I have a real bad taste in my mouth from that. I’ve been using it on my current project and it is a lot more work than just producing the SQL statements. Plus, SQL is a more transitional skill than HQL

Leave a Reply

Your email address will not be published. Required fields are marked *

 

Powered by WordPress