Question

Although obviously not all scenarios can be covered by a single design, is it generally felt now that ORM classes should be passed to and fro between the presentation and business layer (either local or remote), replacing the need for data transfer objects? As far as I can see, using ORM classes presents problems of unnecessary eager loading, context management issues and tight coupling, but also saves a great deal of time and keeps things simple. Is there now a standard approach that generally favours one over the other (for the majority of situations)?

Answer 1

This is very interesting question and one I have been investigating and experimenting with over the pass two years.

I think there really is no right or wrong answer here. I don’t think you can simply say I want one over the other because typically you may want a hybrid depending on what your clients are (webpage,ws,machine and/or local,remote).

The important thing to remember here is what the pros and cons are to each offering and applying this based on your requirements.

For Example:

• If you were using SEAM, then you would want to avoid a heavily layered architecture because you have access to an extended persistence context. Other web technologies without this support tend to work better with a DTO which prepared the state upfront.
• If you are sending a remote message the import thing is to keep it thin and lightweight, a DTO would typically work better here than a rich domain object. Here you can suppress transparently any ORM issues/behavior.
• DTO pattern has the benefit of protecting your clients from domain changes. This is particularly important if your app is a web service, having a domain (entity) object which defines your contract might leave you unstuck at some point.

By wrapping your system in layers and carefully exposing and securing them, you can produce various APIs for many clients of different types.