Especially when you take out the time spent on loading lazy objects during the rendering phase. Because that time would move to the DTO-creation phase when using DTO’s or the make-sure-every-entity-is-initialized-phase in your approach, making the pre-rendering phase longer.

Your last paragraph is a good summary: use the Open Session in View when you can, and only introduce Service Facades and/or DTO’s when you need to. This is similar to what I just replied to your question on the blog about Service Facades and DTO’s. I guess you can say “it depends”.

The DTO model is discussed extensively on the next blog post but I thought that I would say when I would choose not to use Open Session In View. Open Session In View (on a spring based webapp) tethers the web container thread to the database connection. If I where to assign twice as many web threads as the maximum size of my db connection pool it would have little or no effect. Web threads would simply queue for a db connection to be returned to the pool. More significantly the db transaction (when using JTA) would be active over the rendering phase and that can cause increased contention and increased resource pinning within the database. (Without JTA things like JPA transactions actually do a single phase jdbc transaction for the duration of the flush which occurs when the session is closed. This makes holding the transaction open for longer less of an issue when you don’t require JTA).

If I go with a facade instead and scope my db transaction to a façade the db connection will be returned to the pool when the façades returns. I can then move my UI rendering to after the façade method returns and also perform some none-db based UI input validation before calling the façade. I can then keep more web threads working than I have database connections and have shorter JTA transactions. So I can horizontally scale my application layer infront of my db to better effect.

If I know that my app will never need to be horizontally scaled as it is low volume app and I can live with tethering the db pool to my rendering phase then Open Session In View is much easier to develop with so I would use that. (We use the ZK RIA framwork which even has explicit support for Hibernate Session In View). In contrast if I know that I will need to scale out then the added effort of working via façades is the cost of being able to scale out. If the app is low complexity such that the façades between UI controllers and the services looks like too much layering then I might consider in-lining the façade logic into one of the other layers within a spring transaction template which scopes the db transaction (and hence the db transaction).

If I understand correctly, your suggestion is a mix between the two approaches. There is a Service Facade but instead of using DTO’s you have the Service Facade make sure all domain objects are correctly initialized so that you can just return them as-is.

That would work, but it makes the clients layer depend on the domain objects. Which brings me nicely to your other point.

Whether that is good thing or a bad thing is an interesting discussion. Your point that it can make inexperienced developers just write a lot or unnecessary, incorrect, inefficient boilerplate code is a good one. Then again, inexperienced developers are likely to make other mistakes. So then the questions is: do we want architecture to “defend” against inexperienced developers. Or do we perform code reviews andteach how to use the architecture correctly? But that is a different issue altogether.

Back to the point: a good reason to have that isolation layer of the Service Facade/DTO combo is so that you can modify your domain objects without it having a direct impact on your client(s). But that depends on how closely the two are tied. Erik Rozendaal’s comment to my blog on Service Facade and DTO’s has some good points on this.

I agree with @Dimitris that the “option 2″ approaches seem unsatisfactory. Why not just have façades that are use case orientated and @transactional with methods which know how to initialize lazy objects (or call the correct eager queries) and have clients such as the web UI always go via the façades?

I found the following statement strange:

“While purists may argue that this makes your presentation layer depends on your domain objects, it is a compelling approach for simple web applications.”

Surely I want all of my platform at all layers dependent upon my domain objects as they model the business problem space? Anything built to be a business solution should be familiar with, and make reference to, the problem domain. I tend to draw the “domain layer” as a vertical stack to the side of my “cake diagram” of the application logical layers and tell all of the developers that they must try to stick almost exclusively to using the domain objects wherever possible.

We use a highly stateful ajax framework (ZK) for very complex web applications that has a declarative bi-directional databindings feature. I can then bind my domain objects to my web desktop components. So I use my domain objects everywhere within my presentation layer as detached objects. We don’t use open session in view to avoid the scalability issue of leaving the session open whilst building the view. The use case orientated façades that scope the transaction can take care of calling the re-attach logic before any save which you covered in your previous blog on saving detached entities.

I got a cold shiver when I read the recommended strategy of copying the domain objects to DTOs or VOs. On large projects the programmers that don’t have a strong experience of JPA/JDO/Hibernate they are going to think “DTO = result set” and fall back to obsolete patterns. Pretty soon you get an explosion of different but mostly similar DTOs that model the screens that the developers are building. They then makes lots of trips down the stack to pull other similar looking DTO by ID when the current one is not quite the right. JDBC IO saturation ensues and the domain pattern and ORM can go right out of the window.

Something I have noticed is that accessing a collection causes Hibernate to load all the entities in that collection, even if you are just adding or removing an entity. This can become a problem when you have large collections and especially when combined with managing bidirectional associations.