How to implement UnitOfWork on Csla 8

[ecaldentey]

Hi Rocky,

Could you guide me on how to implement a UnitOfWork in CSLA 8?

I need to perform a series of operations on different CSLA objects within a single transaction, such as editing some records in a BusinessListBase, updating a root BusinessBase with children, etc. In other words, multiple operations across different classes, and if any operation fails, revert everything.

Currently, I can do this separately, one class at a time, but if something fails, I have to delete what has been done class by class, which is insecure and inefficient.

In fact, the updates of the BusinessListBase are a kind of UnitOfWork since this class opens the database connection, starts the transaction, then passes control to the child classes that are root BusinessBase with children. But as they know they are part of a BusinessListBase, the items in the list that are root objects have their IsChild property set to true. They skip opening the database connection because they know the BusinessListBase did it, and the same with the transaction. If something happens with any object in the list, the BusinessListBase takes care of the rollback, and if everything is fine, the BusinessListBase commits and informs the UI. In my opinion, it is a good example of UnitOfWork.

What I want to do is something similar but with a UnitOfWork object that contains all the objects involved in the transaction and that is responsible for making the database connection and opening the transaction. If any of the different objects contained in the UnitOfWork report an error, the UnitOfWork should handle the rollback and report the error to the UI; otherwise, it should commit.

Can you guide me on how to do this in CSLA 8 or indicate where I can find an example? I have reviewed the CSLA projects and forums but haven't found clear information regarding what I need to do.

Thank you

[rockfordlhotka]

What I am hearing, is that you have multiple object graphs, each with its own root object, and you need to update these object graphs within a single unit of work?

The easiest way to implement the UoW pattern is typically as a command object that inherits from CommandBase. Here is some pseudocode:

public class MyUnitOfWork : CommandBase<MyUnitOfWork>
{
  // implement one property for each root object

  public static readonly PropertyInfo<MyRoot1> MyRoot1Property = RegisterProperty<MyRoot1>(nameof(MyRoot1));
  public MyRoot1 MyRoot1
  {
    get => ReadProperty(MyRoot1Property);
    set => LoadProperty(MyRoot1Property, value);
  }

  [Create]
  [RunLoca]
  private void Create()
  {}

  [Execute]
  private async Task Execute([Inject] ISqlTransaction transaction, [Inject] IDataPortal<MyRoot1>)
  {
    transaction.Start()
    MyRoot1 = await MyRoot1.SaveAsync();
    // repeat for other object graphs
    transaction.Commit();
  }
}

// calling code with an IDataPortal<MyUnitOfWork> instance
var uow = await commandPortal.CreateAsync();
uow.MyRoot1 = myRoot1;
// set other object graph properties
uow = await commandPortal.ExecuteAsync(uow);
// you now have all the updated object graphs

[rockfordlhotka]

That helps, thank you.

What you are looking for is the concept of composability when it comes to data access, where a root object can be composed with other root objects into a UoW, such that it reuses any pre-existing database transaction.

The easiest way to do this is to use the Csla.Transactional attribute with the TransactionalTypes.TransactionScope option. This uses the built-in ADO.NET transaction manager. As long as all your objects use the same database connection, they should be enlisted in the same transaction scope.

If you are injecting the connection object as a DI service into your DAL objects (which you should be), and the connection object is a scoped service, then the connection should be reused across all operations in the unit of work, and should be enlisted in a transaction thanks to ADO.NET.

        [Update]
        [Transactional(TransactionalTypes.TransactionScope)]
        private async Task UpdateAsync([Inject] PersonDal dal)
        {
            await dal.UpdateAsync(new PersonEntity { Name = Name });
        }

and

        [Execute]
        [Transactional(TransactionalTypes.TransactionScope)]
        private async Task ExecuteAsync([Inject] IDataPortal<PersonEdit> personPortal)
        {
            await personPortal.UpdateAsync(Person);
        }

[ecaldentey]

Indeed, I do as you suggest and use DI to share the database connection service, injecting it into the Dataportal methods because my object interfaces have the definitions.

In the case of a root BusinessBase object, in the Dataportal method, I check if it is a child (IsChild Csla property this.IsChild = true) and with that I know it is a child of a BusinessListBase. With this condition, I perform actions in the database and then call: this.FieldManager.UpdateChildren(this);

On the other hand, if this.IsChild = false, in the Update method of the BusinessClass, I open the database connection and start the transaction.

Therefore, when the root BusinessBase is a property of a CommandBase, I don't know how to recognize this condition. I lack a property, and I am not sure if I need to modify the design of my classes to add a property that allows me to identify the condition of being a property of a CommandBase object or if I can use some Csla property.

Here is an excerpt of how my interfaces are and how the Dataportal methods of a root BusinessBase class look, to better explain the problem. For this example, I simulate the existence of a property IsCommandProperty.

public interface ICustomerDal
{
#region [Interface_Methods]

DbTransaction StartTransaction(Int64 transactionId = 0);
void EndTransaction(bool commit, Int64 transactionId = 0);
void CloseConnection();
decimal FetchId(CustomerGetIdDbTypes getIdDbType = CustomerGetIdDbTypes.CustomerId, string customFilters = "");
CustomerDto FetchObject(CustomerDto customerDto, CustomerSelectDbTypes selectDbType, string customFilters);
List<CustomerDto> FetchList(CustomerDto customerDto, CustomerSelectDbTypes selectDbType, string customFilters);
ResultMethod InsertObject(CustomerDto customerDto, CustomerInsertDbTypes insertDbType, string customFilters);
ResultMethod UpdateObject(CustomerDto customerDto, CustomerUpdateDbTypes updateDbType, string customFilters);
ResultMethod DeleteObject(CustomerDto customerDto, CustomerDeleteDbTypes deleteDbType, string customFilters);

#endregion [Interface_Methods]

}

//Dataportal Methods
#region [Insert_Update_Delete]

[Insert]
[InsertChild]
private void Insert([Inject] ICustomerDal dal, [Inject] ILanguageService serviceLanguage)
{
PerformUpdate(() => dal.InsertObject(LoadData(), (CustomerInsertDbTypes)(this.OptionSelector ?? CustomerInsertDbTypes.InsertDefault), this.CustomFilters), dal);
}

[Update]
[UpdateChild]
private void Update([Inject] ICustomerDal dal, [Inject] ILanguageService serviceLanguage)
{
PerformUpdate(() => dal.UpdateObject(LoadData(), (CustomerUpdateDbTypes)(this.OptionSelector ?? CustomerUpdateDbTypes.UpdateDefault), this.CustomFilters), dal);
}

[Delete]
[DeleteSelfChild]
private void Delete([Inject] ICustomerDal dal, [Inject] ILanguageService serviceLanguage)
{
PerformUpdate(() => dal.DeleteObject(LoadData(), (CustomerDeleteDbTypes)(this.OptionSelector ?? CustomerDeleteDbTypes.DeleteDefault), this.CustomFilters), dal);
}

private void PerformUpdate(Func databaseOperation, ICustomerDal dal)
{

if (this.IsChild || this.IsCommandProperty)
{
	//!!!Code when the BusinessBase root is child of a BusinessListBase or property of a CommandBase!!!
	DoUpdate(databaseOperation, out bool resultStatus, out string resultMsg);

	if (!resultStatus)
	{
		throw new Exception(resultMsg);
	}
}
else
{
	//!!!Code when the root BusinessBase object is operating on its own 
	//and directly controlling the database connection and transaction !!!
	using (var conn = dal.StartTransaction())
	{
		#region [StartTransaction]

		DoUpdate(databaseOperation, out bool resultStatus, out string resultMsg);

		dal.EndTransaction(resultStatus);

		if (!resultStatus)
		{
			throw new Exception(resultMsg);
		}

		#endregion [StartTransaction]
	}
}

}

private void DoUpdate(Func databaseOperation, out bool resultStatus, out string resultMsg)
{
resultStatus = true;
resultMsg = String.Empty;

var resultMethod = databaseOperation();

resultStatus = resultMethod.ResultStatus;

if (resultStatus)
{
	try
	{
		this.FieldManager.UpdateChildren(this);
	}
	catch (Exception ex)
	{
		resultStatus = false;
		resultMsg = ex.Message;
	}
}
else
{
	resultMsg = resultMethod.ResultMsg;
}

}

private CustomerDto LoadData()
{
CustomerDto customerDto = new CustomerDto();

customerDto.CustomerId = this.CustomerId;
customerDto.CompanyName = this.CompanyName;
....
/*----------- Old Properties -----------*/
customerDto.OldCustomerId = this.OldCustomerId;

return customerDto;

}

#endregion [Insert_Update_Delete]

[rockfordlhotka]

On the other hand, if this.IsChild = false, in the Update method of the BusinessClass, I open the database connection and start the transaction.

If you inject an open connection and use the Transactional attribute, then you don't need to open connections or transactions (or commit/rollback) in your code. This should make your code composable, because your root objects shouldn't worry about whether the connection it got injected was already associated with a transaction.

[rockfordlhotka]

@ecaldentey here's a gist that shows the use of the Transactional attribute and an injected connection object. It isn't a unit of work scenario, but it does demonstrate how to allow DI to open the connection, and the data portal to manage the transaction. This way none of your DAL code worries about those details.

https://gist.github.com/rockfordlhotka/e3f6f1cd5e030cfc474818a3f418095d

[ecaldentey]

Hello Rocky,

Thank you for the comprehensive response, and for your time and dedication.

I have currently developed a code generator based on Codesmith that generates all the classes. What I am going to do is remove the references from my interfaces to the methods that handle transactions and add the attribute [Transactional(TransactionalTypes.TransactionScope)] to the dataportal methods. This will allow me to avoid managing transactions manually, which should greatly simplify my code.

Thank you very much for the help.