There is an article in the TheServerSide about designing your applications with a layer of 'Plain Old Java Objects' representing the domain data, and an EJB layer to handle the persistence.
Even if I don't really like the complete solution presented in the article, I think it's difficult to not to agree with the idea that we should use domain classes that are totally independent of the persistence strategy.
I want to use the same Customer class in my Windows client code, in my web application, in the middle tier, in the web services layer, etc, etc. Separating Data From Architecture is a good article about this.
Working with a persistence layer that stores objects to the database is nice, but if you build your application on top of that classes, you are stuck with that persistence implementation, which is not a good idea. If you want to use a persistence layer, use it to persist your domain classes.
I think .NET got it right. I really like the DataSets idea, even if today they do not interop via web services (I hope they will someday), and even if they are too 'relational'. DataSets are 'domain classes on steroids'.
Designing Data Tier Components and Passing Data Through Tiers is a very good MSDN article describing the strategies available in .NET.
12:32:37 AM 
|
