Use Hibernate Entities in the web layer?

[Rapthor]

Hello,

I wonder how to handle my entities in a complete Spring application (persistence, logic, web layer).

I have Hibernate generating entities and corresponding mapping files for me. Now the web layer will work with JSF and managed beans. Should I create DTOs out of the entities to be given to the JSF pages? Otherwise I would have to share the entities with the web layer.

Would this be a good approach since entities are nothing less than POJOs? But changing entities means changing the web layer because it is coupled.

Any suggestions please?

[Rapthor]

I just found an interesting thread about this ... seems as if there would be no reason to create DTOs anymore, when we do not use layers that run on different machines.

http://forum.springframework.org/sho...nsfer+obj ect

[zonski]

To DTO or not to DTO ...

This is a long-running and on-going debate with zealots on both sides of the camp. The forum mentioned in the previous post is pretty representative of the various opinions out there, which range from "Use DTOs or die!" to "DTOs are the work of Satan".

I'm an advocate of "use the approach that solves your needs". Largely this depends on whether you have a single, web-only client or if you have a distributed application (e.g. a desktop application that makes remote calls to the middle tier by RMI/Hessian/Burlap/etc).

From a purity view, the 'correct' approach is to use DTO's as it completely decouples your middle tier from your presentation tier. Those that argue that the use of DTOs 'has no conceivable benefit' have missed two fundamental consequence of exposing your Hibernate entities to the presentation layer:

1. Security is now partially external to your business layer. The presentation layer now has the responsibility of deciding whether a certain attribute (an Employee's email address or birthday for example) should be displayed to the user or not. With a DTO you can restrict this information from ever reaching the presentation tier and so security is absolutely enforced by the middle-tier as it 'should' be.

2. Transactions are now external to your business layer. Since the presentation tier is now potentially triggering database calls, you need to keep your transaction (or database session at least) open. Commits/rollbacks are now outside of the middle-tier. (Generally you only do reads in your presentation layer so this is not a big deal - definitely avoid doing 'writes'!)

From a practical point of view however, both of these factors are generally not a problem for a standard, well-thought-out web-app. Since the presentation layer is server side, it's not really such a problem to let transactions and security seep into the controllers and JSPs.

There is a reasonable amount of extra work and code (though an IDE like JetBrains IDEA significantly helps here!) and even some minor performance/memory considerations involved with DTOs, so if you know you're only going to have a standard web interface go with the exposed Hibernate entities and the OpenSessionInView approach.

If you have a remote client (Swing, mobile phone, non-Java) or some distributed services (B2B) then consider using DTOs. The use of ORM object graphs (i.e. hibernate objects and their links to other objects) causes nothing but trouble when you try to serialize beans down the wire.

Hope that helps,
zonski

[seabludude]

When adopting a Domain Driven Design approach, domain objects should not be exposed to web tier, as argued in the following blog post:
http://ozgwei.blogspot.com/2007/06/d...passed-to.html

[Rapthor]

Thanks both of you.

Very interesting aspects. I did not come to an end yet. I will thouroughly think about the points mentioned. For me it is just a web application without remote calls. Still I have to think about it carefully.

[Jörg Heinicke]

I'm an advocate of "use the approach that solves your needs".

I like that camp a lot more

1. Security is now partially external to your business layer.

I agree. Other implementation technique to restrict access is the usage of special presentation layer interfaces together with proxies, so cast won't work.

2. Transactions are now external to your business layer. Since the presentation tier is now potentially triggering database calls, you need to keep your transaction (or database session at least) open. Commits/rollbacks are now outside of the middle-tier.

Here I don't agree. What you describe is Open Session In View. Nobody forces you to use it. I restrict my transactions to the business layer. There are no database calls from the presentation layer. I don't say this solution has other flaws: I need to either eager load some associations or provide some initializeAssociation() methods on my service. At least I prefer this solution much more than OSIV since it's more controllable.

Jörg

[zonski]

Quote:
Originally Posted by zonski
2. Transactions are now external to your business layer. Since the presentation tier is now potentially triggering database calls, you need to keep your transaction (or database session at least) open. Commits/rollbacks are now outside of the middle-tier.

Here I don't agree. What you describe is Open Session In View. Nobody forces you to use it. I restrict my transactions to the business layer. There are no database calls from the presentation layer. I don't say this solution has other flaws: I need to either eager load some associations or provide some initializeAssociation() methods on my service. At least I prefer this solution much more than OSIV since it's more controllable.

Yep, that's definitely a good third option - use some form of eager loading to populate only those fields that you are going to use and then close the transaction before handing the Entity out to the presentation layer. This solves the issue of security, transactions and business rules seeping into your presentation layer.

It does come at the price of a weaker service API and compiler support (i.e. if you forget to eager load Person.emailAddress and you try to use it you won't find out until runtime). With OSIV you avoid this problem but have the other transaction problems mentioned. With DTO you can avoid both these problems but with the hassle of extra code.

Unfortunately there's no single solution that wins out. It comes down to weighing off the benefits and hassles of each against your specific requirements.

[Rapthor]

I think I will use DTOs instead of entities in the presentation layer. The other approaches somehow smell. If it is only the extra code to maintain which makes this solution "worse" I will however take this approach since I am generating my entities. I think I'll find a way to generate the DTOs as well.

Thank you!

[seabludude]

Keep an eye on the ROO (Real Object Oriented) project created by Ben Alex, the creator of Acegi Security.

In a ROO application, DTOs are generated (and maintained in the lifecycle) according to the domain model.

[debasishg]

I think I will use DTOs instead of entities in the presentation layer. The other approaches somehow smell. If it is only the extra code to maintain which makes this solution "worse" I will however take this approach since I am generating my entities. I think I'll find a way to generate the DTOs as well.

Why do you feel that other approaches somehow smell ? I am all for using domain entities in the presentation layer. If you read the Expert Spring MVC book or the Hibernate book, both of them encourage using smart domain models and reusing domain objects in the presentation layer. The Spring MVC book recommends using domain objects as command objects and the Hibernate book recommends doing away with the behviorless JSF backing beans in favor of smart POJOs in SEAM.

Unless of course, you have a remoting scenario - still there u can use EJBs and container managed remoting. Unless there is a forceful enough reason, I would not go the DTO way. Too much boilerplates .. objects without behavior .. :-(

My 2 cents.
- Debasish