If you are using the DTO model, then you are using a data access layer (DAL). In this case the DAL must be responsible for managing all transactions - neither CSLA nor your DataPortal_XYZ methods should be responsible for any transactions.
In other words, you should use Manual transactions in CSLA (the default), and your DAL should figure out how to start/commit/rollback the transaction as appropriate.
Remember that the DTO passed to the DAL includes all data parent, child, everything, and so the DAL entry point is an ideal place to start and commit a transaction.
Rocky,
That sounds simple for fetching the data. Updates are less trivial though.
Would your DTOs contain IsDirty, IsNew and IsDeleted properties so that the DAL can decide what action to take?
Do you see things working like something like this?
1) DataPortal_Update called
2) Root object creates RootDto instance from own member variables
3) Root object sets RootDto.ChildList to result of friend function on child collection
[Me.ChildCollection.MakeUpdateDto() ]
...
4) RootDal.Update is called and RootDto instance passed to it.
5) RootDal.Update creates transaction
6) RootDal.Update navigates the DTO object graph and persists according to the Is... flags on each DTO
7) RootDal.Update commits transaction
I think it's time you enhanced the Data Layer Demo! :)
Martin.
Yes, the DTOs must contain (at least) IsNew and IsDeleted
properties. Depending on how you build the DAL, you might have an IsDirty
property, or you might choose to only create DTOs for dirty objects –
though that gets complex when dealing with non-dirty parent objects of dirty
child objects…
CSLA 3.5 is primarily focused on enhancing support for data
access (thanks to LINQ and EF). Due to that, you can expect to see DeepData
and/or ProjectTracker change to accommodate LINQ, and probably DTOs as well.
Rocky
Copyright (c) Marimer LLC