OK, that's still a bit backwards. The controller should be concerned with translating between the View (ViewModel) and the Business Logic, not controlling a transaction which is something that belongs in the Data Layer and possibly controlled by the Business Logic. So long as the last call you make in the Business Logic is the DbContext.SaveChanges, all the changes the Business Logic makes will be wrapped in a Transaction AUTOMATICALLY. You don't have to create a transaction yourself!
public class BusinessLogic
{
private MyDbContext context = new MyDbContext();
public void BusinessFunction1()
{
// Don't call SaveChanges in here.
}
public void BusinessFunction2()
{
// Don't call SaveChanges in here.
}
public void SaveChanges()
{
// All changes made above will automatically be wrapped
// in a transaction by EF.
context.SaveChanges();
}
public void Dispose()
{
context.Dispose();
}
}
Besides, you already linked to the article that shows you how to do it! I already linked to a couple of articles that shows you the pitfalls of what you want to do. The problem with what you want to do is that you have to be VERY careful that the transaction mode you use doesn't LOCK THE ENTIRE TABLE while you do your transaction processing. If you're not careful, the lock will prevent other instances from even reading the data in locked tables, preventing other users of your web site from seeing pages that are backed by data!
A guide to posting questions on CodeProject
How to debug small programs
Dave Kreskowiak
