In our application, we have a CommandBase that descends from Csla.CommandBase.
We provide for some implementation in DataPortal_Execute, executing "ExecuteCore" (virtual) w/ the implementation in the concrete Command classes - wrapping it with a try / catch / EnterpriseLibrary.HandleException.
Some commands are transactional in nature and some are not. But if DataPortal_Execute is implemented in our base Command object, it obviously doesn't lend itself to having the attribute uniquely defined for each Command class.
An alternative is to have a TransactionalCommandBase class which inherits from our CommandBase class with the only implementation being in DataPortal_Execute: base.DataPortal_Execute(). It would be decorated with the transactional attribute and would be the base class for any transactional commands.
Is there another easy alternative to this approach that people have used that would behave against the examination of this attribute in the CSLA framework to determine which DataPortal to instantiate (Simple, Transactional, etc).
Hi,
So what you are doing is implementing a "base class" Command that calls a virtual method in your implementation so that your ExceptionHandling is implemented just once. Is this for logging purposes only or do you actually handle exceptions and possible return OK even if exception was thrown?
Thank you for the response.
Yes on the virtual method and exception handling occuring once.
Primarily for exception handling - I'm using Enterprise Library, so it may have various exception handlers including rethrowing a different exception (to hide the exception details from the client) as well as a custom logging handler configured to log the exception as well as a private reflection of the business object of the data portal to store as XML along w/ the exception details.
I can't really have it occur in OnDataPortalException b/c I can't catch and handle (potentially rethrowing) the exception from there. It's already been caught by CSLA.
It sounds like the hook may be exactly what I'm looking for.
Another thing you could consider, if you are just using TransactionScope and not Enterprise Services, is to have your base class manage the transaction.
Remember that the CSLA Transactional attribute, when using TransactionScope, is only saving you 4 lines of code, two of which are brackets 
Just have your base class decide (based on some protect property?) whether the subclass needs a transaction or not, and either wrap or don't wrap the subclass method call in a TransactionScope.
I think the only difference would be that the Invoke, InvokeComplete, etc would not be considered part of the transaction, whereas with TransactionalDataPortal they would be... right?
Copyright (c) Marimer LLC