I have downloaded Rocky's presentation "Deep Data" that explains his thoughts on implementation of Fetch operation for a parent-child relationship in a seperate data access layer.
We would like to implement a Data Access Layer using Data Transfer Objects approach. I am interested in identifying how the data access layer would handle the insert, update and delete operations for root-childen relationship data transfer objects.
For e.g. Looking at the same example that Rocky discussed in his presentation about, Orders -> Line Items -> LineItemDetail, if I had different data transfer objects for each of these, How could the Order Root DTO object determine inserting/updating/deleting itself and its children Items and its grandchildren LineItemDetail. We want to implement transactions to ensure ACIDity is maintained.
Our initial thought was to have stateful DTO objects just like the business objects do so that the root object can start a transaction if it has changed state (is new/dirty) and save only those child objects whose state is new/dirty. In this manner, we achieve persisting objects if required and also identifying which operation(insert/update) is applicable.
Is this a suitable approach? Does Rocky have any presentations on his thoughts of implementing other CRUD operations in the data access layer?
To support insert/update/delete you need to pass the IsNew/IsDeleted values from your business objects through to the DAL.
The easiest way to do this (and I think best way) is to include those properties in the DTOs.
Alternately you could create some "context" object that would keep those values and pass both that "context" object and the DTO to the DAL.
But I think you should view the DTOs as messages, not objects. In other words, the DataPortal_XYZ methods are sending messages to the DAL, and the DAL then does its work. The messages should be self-contained, and that means that they would need not only the business data, but also the metadata like IsNew and IsDeleted.
The reason the message approach is best, is because it translates well to a service-oriented model, meaning that your "DAL" could actually be a set of web services, WCF services, etc. And this technique doesn't prevent you from using LINQ to SQL or ADO.NET EF.
Copyright (c) Marimer LLC