I pose this question for anyone who has experience in both using and not using data persistence objects in their domain design (i'm talking about mid to large size applications)
What are advantages of using persistence objects in conjunction with domain objects to move data to and from the data layer (database, files, etc) To me it seems like having the data access ORM code in the actual domain object gives that object total control and flexibility over handling/validating its own data with no performance overhead. All domain specific logic is in one place which makes maintenance easier if the busines rules need to be changed.
I would be very interested if anyone has a good, real-life example or explanation of why using Persistence Objects is the way to go.
Thanks,
eric
Using Persistence Objects: What are the advantages?
Racing Snake
Eric,
Considering you're talking about mid to large size applications, I guess you talk about applications made by more than one developer
Imagine you and me, we work together in such kind of applications. It could happen that I was hired because I'm the expert with persistence mechanisms (I mean, ADO.NET 2.0, JDBC, XML support in SQL Server 2005, Oracle stored procedures, ... whatever it is), while you were hired because your knowledge about the business (the use cases, processes, business rules, legal aspects, etc)
If that is the case, the problem about putting your output and mine in the same place (that is, classes containing domain and persistence logic as well) could be hard to maintain. Imagine this scenario: for corporate reasons I have to change some aspect in the persistence mechanism, with impact in the business entities. Let's say, the DBA establishes that Id column in every table must be IDENTITY so every creational method must consider that the Id property is something assignable by database (not by the application anymore). So I have to apply this change on every shared class
What happens if you are in the middle of certain development, involving let's say, not less than 7 shared entities and I have to apply my change soon What if your change needs 3 weeks to be done Should I wait you finish, check in your classes, testers do their job on them and so on, before apply my change Or should I ask you that, considering you have checked these classes out, you apply the change in Id Property behaviour for me
I accept the following: if the premise isn't that, if you are responsible for all the logic (business and persistence) in a 50% of the classes and I do the same in the other 50%, the problem I depicted wouldn't appear. But in terms of complexity, we both should care about business and persistence as well -less specialization that could impact in the quality of results-. Again, I insist you are talking about mid to large size applications
In my experience I had this one and some others problems, when a class contained "expertise" from several people. In terms of process (coordination) and also when some component went wrong in execution, it wasn't so clear who in the team should care about that (normally, the last one who changed the component but in a certain percentage the source of the problem was a previous change, not manifested before)
Today you have a way, in CLR 2.0 objects, of putting domain and persistence logic in the same class but with a clear, physical separation of concerns: Partial Classes. I think that partial classes are a fake way to apply Template or Strategy pattern, but at least, a effective way to avoid coupling between domain and persistence logic
Still if you are encouraged to put all in one place, just take a glance about what Partial Classes are and how you can take advantage of them at
http://msdn.microsoft.com/msdnmag/issues/06/00/C20/default.aspx
Personally, and mostly in large projects, I prefer Strategy Pattern, but that implies breaking the logic in two or more classes (just a brief explanation of this pattern idea at http://msdn.microsoft.com/msdnmag/issues/05/07/DesignPatterns/). Still partial classes will permit you avoid the coupling between both kind of logic
vimalbharathi
If by "persistence objects" you mean the domain objects should also take care of persisting themselves - I don't think that is a good direction. For one there is the matter of single responsibility principle. saving to DB and business logic are two concerns - you can read about SRP here. basically you'd get unwanted side-effects like the objects will get larger, changes in the DB structure will mean your object change. A better approach is to externalize O/R mapping from the code altogether
Arnon