No, I think you are right to ask these questions. Ridged layering can be naive. I really do think it comes down to what you application is trying to achieve, and you must balance the different approaches that best suit your requirements. While trying to position yourself for re- factoring and the evolution of your app. It may sound like a cop out and doesn't give you any answers but its true.
And remember, this years hot design pattern will be next years anti- pattern. Do what feels right, without being stupid. :) People started to realized the limitations of the anemic domain model. So we moved to the "rich domain model", which was for the most part, what we were doing previously. :) I have had my fair share of issuing the minority report. Let the flames begin... On Jul 29, 9:29 am, Moandji Ezana <[email protected]> wrote: > Hi, > I was wondering if the standard application-layering guidelines was still > the recommended practice. > > Guidelines I'm thinking of are: > - layers: controller, service, DAO > - one DAO and service per entity > - each layer knows only the one directly below it > - services and DAOs have interfaces that the layer above uses > > My impression is that these guidelines arose to ease physical separation of > an application onto several different machines. As such, they often don't > make sense: > - very often, the application itself is not split up: at most, it is on one > machine, the DB on another. > - the interfaces, *especially* on services, buy you very little > - rigidly funneling everything through a service layer creates a lot of > boilerplate, pass-through code > - services tend to lead to an anemic domain model, which ends up > complicating things > - and finally, having a service and DAO per entity means that to look up an > entity by id from a controller, I need to create 2 interfaces and 2 classes > just to call a trivial method. > > The result is a lot of code that does very little. > > I brought this up at work today and suggested a rule-breaking simplification > (basically, use a non-entity-specific CrudDao in controllers and services to > handle simple cases) and got shot down: > - what if we need to introduce centralised business logic later on? > - what if we need to optimise particular queries? > - things should be consistent, even if it leads to boilerplate > > My gut feeling was YAGNI and premature optimisation, but I'm wondering if > I'm being short-sighted? Are there really hidden dangers to breaking the > rigid layering pattern? > > Moandji --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
