This week's giveaways are in the MongoDB and Jobs Discussion forums. We're giving away four copies of Mongo DB Applied Patterns and 4 resume reviews from Five Year Itch and have the authors/reps on-line! See this thread and this one for details.
Currently the project on which I am working on a j2ee project which is being developed with Spring, Hibernate and struts. The business layer consists of simple java beans with no behavior in them only properties with getter and setter methods.The services in business layer acts on these simple java beans like populate them from data access data and then return to presentation tier.My questions is that is it object oriented way of designing business layer or simply the procedure way in which the data and the functions on which they operate are not together. Please provide your thoughts and inputs on how the business logic is designed and implemented in j2ee application, is the domain model just contains simple objects with no business methods in it and services are written on these java beans which implements the business logic.
whats are the design patterns used in the development of business layer.
Data-only domain objects are smelly. It doesn't mean they're necessarily wrong but it's an indication that maybe your business service classes might be overstepping their bounds. There are no cut and dry rules for this kind of thing though, as far as I can tell. I use testing to help me find bad choices. When it's hard to test some behavior because of too much setup or too much coupling, then I know it's probably time to refactor. I can't think of a good example off the top of my head but I know I've encountered situations where I've moved logic from a business service class back into a domain object after detecting the "data only domain object" smell. The rule of thumb I use: Business Services coordinate work between different objects. Domain objects keep track of the integrity of its relationships with other objects. Another guideline I use that helps with properly assigning responsibilities: Define the transaction boundaries at the business service level, not at the domain object level.