CommandBase & Transactional

CommandBase & Transactional

Old forum URL:

skagen00 posted on Monday, May 10, 2010

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).

JonnyBee replied on Tuesday, May 11, 2010


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?

  1. A: If it is for logging purposes only then you could also consider to only implement DataPortal_OnDataPortalException method in your base class and use Tracsactional attributes as normal on DataPortal_Execute. There is even DataPortal_OnDataPortalInvoke and DataPortal_OnDataPortalInvokeComplete available for logging when call runs OK.
  2. If you wish to change the actual exception being returned in DataPortalResult, then I am working on Bug:679 to provide for this in a hook in the  DataPortal. That is - having one common hook for all DataPortal calls (not including ChildXYZ calls) to inspect the Exception - log and rethrow original or transform to another execption for the client.



skagen00 replied on Tuesday, May 11, 2010

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.


RockfordLhotka replied on Tuesday, May 11, 2010

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 Smile

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.

skagen00 replied on Tuesday, May 11, 2010

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