Best practices question with Entities, service classes, and command objects

Entity's are classes that map directly to our database (which we use for Hibernate).

Our service classes contain business logic with these Entities before DAO is called.

We also have Command Objects, which are POJO's that relate to specific views. I've been told that the Entities themselves shouldn't be used as command objects, but the answer I was given for "why" wasn't sufficient. I'm hoping someone here can give me that answer.

Some of our views are incredibly simple. They have no more properties th开发者_如何学JAVAan the entities themselves. It seems pointless to me to map an entity to a command object which is basically a mirror image of the entity.

It seems that there may be some confusion in the naming of your objects. Command objects typically provide a single execute() method (with parameters) that operate on a given entity or domain object to alter it's state in accordance with the business logic. It's a very neat way of encapsulating business logic into simple objects that have very limited scope to mutate other objects.

It would seem, then, that the design you're working with actually performs some kind of bridge between Data Transfer Objects (DTOs or entities) and value objects (VOs or Command objects in your system). This can be quite wasteful since all you're doing is copying the same data into different objects.

The Data Access Object (DAO) acting on the Data Transfer Object (DTO or entity) pattern is well established and promotes good separation between layers. Typically, Hibernate will map the entities to the database, and lazily load collections within them. This is where most designs trip up because they don't allow for correct initialisation of collections because the session has gone once the thread of execution leaves the DAO. I imagine that the "Command objects" in the JSPs are actually subsets of the entities with various collections having been initialised by means of Hibernate queries.

I would suggest that you ditch the "Command objects" in favour of suitably initialised entities which would simplify your design in one respect but open you up to a potential issue in another. You will need to carefully control how collections are referenced and initialised by your JSPs. You may find yourself having to look into the Open Session In View pattern to ensure that a Hibernate Session object is available when the JSP calls the getCollection() method on some DTO that has not been initialised.

I see no problem in re-using the domain model objects (what you are calling Entities) throughout all layers of your application - the controllers, views, service classes and DAO layer. This is a common design which you see often.

There is no problem with this if and only if you have a true separation of layers - the controllers get the model objects from the service layer, the service layer gets the model objects from the DAO layer, etc.

If you have a design where you load the Employee objects from the database by calling manager.getEmployees() from the view layer, then this will not work well.