I see I will never understand this architecture and I do not think it is possible to find motivation for code dublication.
If you need adapter then use adapter for thing like lazy Set,
if you need additional operations for view then create new class and delegate persistent state manipulation operations for persistent object,
If you need to "hidde" some state manipulation from view then use private members.
Do you have some realistic example to motivate two model ?

This is the real example:
System has service layer (DAO) and this layer is used by two WEB interfaces ( intranet and internet) and for JMS.

Doe's it means I need 2 object models for web, 1 for persistence and 1 for messaging ? I use the same model for all without problems. I need to integrate "desktop" interface, it is not started at this time, but I will use the same model too.

I use the same model for all. In my layer description, #1 and #2 are two parts of the same model. No need for delegation -- Hibernate creates my behavioral domain model objects -- and Hibernate generates the data POJOs that are the base classes.

I'm sorry I'm not able to explain this in a way that makes sense to you, but the bottom line always is that there are lots of ways to do it and if your code works then who am I to complain? ;-)

Cheers!
Rob

Most apps I work on use service layer pattern, and delegates business logic to the hib mapped entities. I really like this approach, as it makes unit testing of business logic without a db very easy. No Hibernate code in domain model is usually necessary if one gets the mappings correct. It allows me to put behavior in the object who owns the data.

I use a DTO in an update situation only (where it is used to hold parameters for a "request" to change the business model). Where the granularity of the request is not 1-1 with the object model.

Model objects used by display tier, are the real hib objects. This removes some of the maintenance of having changes in the domain needing changes to all the "copies" or DTO's laying around.

? Is anyone passing their struts forms directly into the service layer when the client (struts action) wants to do an update?

--James

I am sure this is antipatern. Is it meens you need to generate models for
all interfaces in app ? Some of my aplications have many interfaces and use the same model for browser,JMS and email.

Of course it is wrong to remove 2. Your domain model must be independant from the views.
You cannot code your business rules thinking in terms of views????

If you don't have to see an entity on a view, this doesn't mean that this entity is not usefull to make your business.

I use this way for struts forms (struts with "actionforms" is antipattern itself too, but this is not about it)

class MyActionForm extends BaseForm{

POJA getPOJO(){

return pojo;

}

ActionErrors validate(HttpRequest ....


}


I persit "pojo", not "MyActionForm" itself and form has single persistent object property "POJO". When I need to change persistent state, I delegete it for pojo (or some persistent data structure ).


ActionForward perform( ...

save(form.getPOJO());

}

Forms,Actions is not a model it just adapters for http .

from my point of view DTOs are evil because they do not promote a good OO design on the client side. if you have DTOs (=data) plus session ejbs (=function) then your client app will most likeley have a poor OO design because function and data are treated by two separate entities.

Instead of writing customer.getOrders(); you write serviceLocator.lookupCustomerService() and then service.findOrdersForCustomer(123); ...

I am looking for a way to overcome this sort of problem. Any ideas?

do you agree about the fact that :
- a view can represent parts of n objects
- an object can be show in n views

for example consider an order, a client, a product

you have a view to show product details
another to show client detail
another to show order general informations an so the name of the client who passed the order (here you don't need anything else than the name).

You click on order detail, you have all the order lines in which you have the name of the product....

I can't image you're thinking that your domain model must match which the representations you need to have...

Maybe i missunderstood your point of view...

Yes, it is a good motivation to have single model for all views.

I very much agree with dirkschmidts point, I really think DTOs are an evil thing. Basically this is all the way back to the structs of the C age. I really think both view and application logic should operate on the same domain model. If you need to restrict client access somehow use interfaces, and let the view work on the interfaces only, or use delegation/subclassing.

IMHO if you can't do something.getXXX() anymore in a view/client, you are seriously fucked :) Of course this gets you some other problems like object graph partitioning, to not load the whole object graph. I think Hibernates lazy loading features do a great job here allready on the server side, but it gets really nasty if you have rich-client applications where lazy loading carries a potentially large overhead.

I kind of like the idea behind Entity Beans remoting, if that would not make them totally unusable because of network overhead.

So IMHO, you should really try to reduce additional layers as much as possible, keep one domain model and try to use this domain model from the view, too. There is much to much overengineering around, promoting things like DTOs/DAOs and all that stuff in the name of the magical "decoupling", which will not be of use in most cases anyways. I allways try to stick with the YAGNI principle.

Just my two cents :)

I have put some thoughts I have about the problem in general and carrierwave in specific on a wiki page at http://www.hibernate.org/177.html - would be nice to get some more thoughts colected.

My problem with the whole "client just works with the business objects" model is that there are obviously a lot of business methods that involve persistent changes beyond just adding new items to the local object graph. I can see how you can do all kinds of gets, sets, new()s, adds, removes on the client side.

But how can you call business logic (say, something like Order.calculateCurrentDiscount()) when that involves doing a bunch of database hits? How can you work with NON-cascading collections in a convenient way? What if you don't want to send all your classes over to the client side?

Heck, the whole conversation assumes that you *have* a view layer. Why not do away with the view layer altogether and just have a fat client with the entire domain model right there?

The reasons to have a view layer often have more to do with *separating* your UI from your business logic, because either it is a large round-trip for each client invocation (and hence you need to batch up objects and provide a higher-leve service layer, since your domain model is too fine-grained to be efficiently accessible remotely); or because you want to keep all domain operations *out* of the view layer (since you want to be able to change out your view layer, and you don't want to mix logic and presentation). Both of these reasons are kind of fundamental forces driving the existence of a view layer *at all*, and pushing business objects (and business object behavior) closer to the view layer goes against those forces.

Cheers,
Rob

A couple of thoughts. I have been giving this a lot of thought over the past 3 months for a proposal I am making to my bosses regarding a change in our application architecture. We currently have this pretty typically service layer setup where the service layer mediates between the UI and the domain model using DTOs as the exchange mechanism.

Are DTOs evil? I kind of go back and forth on this. In gerneral, no I don't think DTOs are evil. I think the amount of my time they waste is evil, but that is where something like CarrierWave comes into play by helping to manage not only the generation of the DTOs, but also the marshalling between DTO and domain entity.

I think it really comes down to the type of application architecture and topology you use. In a fully-colocated servlet-based or fat-client stack, DTOs probably don't make that much sense. Just open the Hibernate session and manipulate your entities at will. But what if you need to split that servlet-based stack into vertical partitioning for network security or clustering reasons? Now how do I manage this? I can't simply "Open Session in View" anymore... So I use Hibernate's disconnected object support.

But consider a product built using Hibernate that exposes an API in this fashion, that you as a developer need to interact with. So you retreive an object and then attempt to access one of it's properties (which happens to be lazy loaded). Boom, lazy init exception. "But the API says that object has that property..." Yes, I know, you could just simply initialize that lazy property prior to sending it outside of the persistence-context; but where does it stop? How deep should I init? Disconnected object support is great in all kinds of scenarios, but it certainly isn't a catch all.

I just don't think there is a hard-and-fast rule here that says you should never be using DTOs; and especially on the argument that they're not true object because they only represent data. Pure data representations are uber-useful for all kinds of things. To me, you're fooling yourself if you think you need a domain entity with all its domain logic intact to populate an html <select> list (if your using JSF or Tapestry or WebOGNL, then thats a different story).

Also note that nothing stops you from having "actions" on DTOs, (they are no longer DTOs...). CarrierWave for example has this notion of command invocation from the client-side: Call an action on an Image (the CW DTO) and it will be proxied for execution on the server. This is quite an interesting area.

I think you do not need domain model as objects in this case, use DTO as "persitent object". It is not OOP, but it is nothing bad to have DB as chema model. I think hidden model between service and database is useless.