Thursday 14 May 2009

Redundant Layers

There been an interesting difference of opinion on the blogs of Ayende and Greg Young regarding the usage of the Repository pattern. Whilst some great points were made on both sides, I tend to agree with Ayende's view that advances in tooling can render patterns, that we have become accustomed to using, redundant. In this case he argues that NHibernate has left little reason to implement Repository any more.

We segregate our applications into separate layers to help us manage the complexity of differing concerns. But we should accept that as new layers are added to an application, overall complexity of that application increases. If I was able to succinctly express my entire application in a single text file, without recourse to layers, I would. That is not (yet) possible so I use a layered approach.

As advances are made in tooling we need to constantly re-evaluate our use of layers and patterns to see it they have been superseded by technological advances. Take MVC as an example; had I been a Smalltalk programmer fifteen years ago I would have needed to create a controller for every widget. As tooling has advanced this has become unnecessary and we now have a different kind of MVC.

All too often I see applications where the architecture has been treated like a check list of layers. DTOs - check, domain - check, web services - check, repository - check; you get the idea. For me there has to be a very good reason for creating a new layer in my application. Do I really need that abstraction? If not, I don't feel compelled to include it. 90% of the applications I work with use a domain model. But that doesn't mean I always include that layer. A simple CRUD application with a few validation rules probably only requires a DAL and few DTOs and a presentation layer, for example.

We need to constantly question ourselves and the decisions we make about architecture, and should only implement layers where we feel there is a need; not because that's the way we've always done so.