The ones of you following TSS have probably seen the debate between Floy Marinescu and Ted Neward about the history and intentions of EJB.
In this latest post Ted responds to some comments by Keith Donald regarding the discussion. Read it all to get the big picture, but they are currently discussing the “dangers” of POJO.
The context that I see is here is largely distribution (and a bunch of other stuff, they’ve lost me on what they’re discussing actually), and I think Ted has some worries that technologies like Spring will lead developers to misuse it’s possibilities. They might think that you can do distribution seamlessly with a complete POJO model just like you were in process with the whole thing. It’s not Springs’ fault, they just give us the tools to do things easier, but people will misinterpet when they want to. 😉 It relates to the problem you also saw/see when EJBs are used for distribution and the interfaces is not thought through. You will get fine-grained methods, with large object graphs in their signature. This causes frequent calls across the network and large chunks of data for serialisation. Ted doesn’t think that is Effective Enterprise Java. 😉
I have learned the hard way through the last year that you can’t think of most things a beeing absracted completely away just because you create layers and interfaces. You will have to consider what is happening behind the interfaces. As an example the DB operations for a TopLink DAO layer does not correspond to what a DAO layer for Hibernate or pure JDBC would look like. And you have to take into consideration how it handles lazy loading and caching. I still use the DAO pattern for its ability to give structure to my system, but it doesn’t let you switch persistence technology seamlessly. Maybe between two JDBC implementations.
It is the same for distribution. Recless calling through the network with large chunks of data will kill your performance sooner or later. Actually it’s coupled with the DAO too. If you try to pass “seamlessly” objects from your domain model over the distributed interface it will actually trigger ALL the lazy loading for those objects, and might lead to a massive load operation (of course depending on the design of your relations). Some time ago I actually didn’t see the use for DTOs, but I do now. Just don’t view them as something closely related to your domain model, view them as separate objects that’s not really very object-oriented, and contain just the required data to transport for remote processing.