Some thoughts on layering

One of the topics that's come up repeatedly at SpringOne so far is the notion that Separation of Concerns, and layering, is essential if your app is going to be 'well designed'. I'm not sure I agree.

I absolutely agree that SoC is important. You shouldn't have one class interacting with, say, the HTTP APIs and the Hibernate APIs, (nor even your Accounting API and your Authorisation API) unless your app is truly tiny. But I don't agree that, in order to do this, you need to have an inviolable set of layers (DAO, BO, Service, Web…) that each class needs to be pigeon–holed into. Just keep your classes small, well–encapsulated and consistent, and the SoC will take care of itself.

I suppose that if you're working on a truly huge project, with hundreds of developers and tens of thousands of classes, then maybe some kind of stronger layering is appropriate. But suggesting that this implies it should be used on all projects is like saying that when I build a wall in my garden, I should do a wind–loading finite element analysis and an earthquake–proofing design. It's just never going to matter.

Our most complex projects (sitebuilder2, blogbuilder) have less than a thousand classes each, not including tests, and usually only 3 or 4 developers. And those are fairly complicated applications; IME they're fairly representative of the kind of apps that a lot of people are writing; many of our apps are much simpler than this. It doesn't seem like we should loose a lot of sleep trying to adopt an architecture that's suited to super–massive apps.

Chris May : 16 Jun 2006 08:46 |  Tags: Java Springone |  Comments (0) |  Report a problem