Hi Rocky,
looking at the unit of work stereotype, but specially the data update UOW,
I am concerned with a possible misusage. Looking at your example from the new eBook "Using Csla 4: Creating Business Objects" :
[Transactional(TransactionalTypes.TransactionScope)]
private void DataPortal_Execute()
{
CustomerEdit = CustomerEdit.Save();
SalesOrderEdit = SalesOrderEdit.Save();
}
What yould you suggest to prevent the user, UI-developer, or any other code from calling Save on each object individually in the context of that specific use case?
I think we are trading off data integrity against convenience here, and you should mention it in the book...
unless there is a solution for it.
That is a good point, though it has more to do with the various transaction concerns I'm discussing in the Data Access ebook than with the UOW concept in Creating Business Objects.
This is (in my experience) a very rare thing - to combine saving multiple objects like the example. And usually it is a matter of convenience, not a transactional construct. I don't think I've encountered a case where the objects couldn't also be saved separately, though I am sure that could happen.
And I suppose if you really did have to have both commit in a single transaction, you'd use a BusinessBase and those two classes would become child objects instead of roots.
Copyright (c) Marimer LLC