I currently have a generic Azure repository AzureRepository<TEntity> store internally a list of table transaction actions like so.
private readonly IList<TableTransactionAction> tableTransactionActions;
The generic repository implements CRUD methods like this..
public void Delete(TEntity entity)
{
tableTransactionActions.Add(new TableTransactionAction(TableTransactionActionType.Add, entity));
}
public void Insert(TEntity entity)
{
tableTransactionActions.Add(new TableTransactionAction(TableTransactionActionType.Add, entity));
}
IUnitOfWork abstraction
public interface IUnitOfWork : IDisposable
{
int SaveChanges();
Task <int> SaveChangesAsync();
bool BeginTransaction();
bool Commit();
Task <bool> CommitAsync();
void Rollback();
}
Question
Would you expose the internal list of TableTransactionActions to the unit of work to perform a commit, or rollback in a batch? How would you properly implement repository/unit of work to perform batched CRUD updates (not read of course)? Properly is subjective of course, however, I am looking for an answer that is well supported and makes a lot of sense in the context of Azure.Data.Tables SDK. Feel free to give direction instead of directly answering the question
I am open to creating more layers of abstractions as well like IDataContext.
Assume that I have a mechanism for retrieving repository instances of any type within the IUnitOfWork