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 -~----------~----~----~----~------~----~------~--~---
