Persistence with EntityFramework in ASP.NET MVC application

In my ASP.NET MVC application I need to implement persistence of data. I've choose Entity Framework for its ability to create classes, database tables and queries from entity model so that I don't have to write SQL table creation or Linq to SQL queries by hand. So simplicity is my goal.

My approach was to create model and than a custom HttpModule that gets called at the and of each request and that just called SaveChanges() on the context. That made my life very hard - entity framework kept throwing very strange exception. Sometimes it worked - no exception but sometimes it did not. First I was trying to fix the problems one by one but when I got another one I realized that my general approach is probably wrong.

So that is the general practice to implement for implementing persistence in ASP.NET MVC application ? Do I just call saveChanges after each change ? Isn't that little inefficient ? And I don't know how to do that with Services patter anyway (services work with entities so I'd have to pass context instance to them so that they could save changes if they make some).

Some links to study materials or tutorials are also appreciated.

---

Note: this question asks for programing practice. I ask those who will consider it vague to bear in mind that it is still solving my very particular problem and right technique will 开发者_C百科save me a lot of technical problems before voting to close.

---

You just need to make sure SaveChanges gets called before your request finishes. At the bottom of a controller action is an ideal place. My controller actions typically look like this:

public ActionResult SomeAction(...) 
{
    _repository.DoSomething();
    ...
    _repository.DoSomethingElse();
    ...
    _repository.SaveChanges();
    return View(...);
}

This has the added benefit that if an exception gets thrown, then SaveChanges will not get called. And you can either handle the exception in the action or in Controller.OnException.

---

It's going to be no more or less efficient than calling a stored procedure that many number of times (with respect to number of connections that need to be made).

Nominally, you would make all your changes to the object set, then SaveChanges to commit all those changes.

So instead of doing this:

mySet.Objects.Add(someObject);
mySet.SaveChanges();
mySet.OtherObjects.Add(someOtherObject);
mySet.SaveChanges();

You just need to do:

mySet.Objects.Add(someObject);
mySet.OtherObjects.Add(someOtherObject);
mySet.SaveChanges();
// Commits Both Changes

---

Usually your data access is wrapped by an object implementing the repsitory pattern. You then invoke a Save() method on the repository.

Something like

var customer = customerRepository.Get(id);
customer.FirstName = firstName;
customer.LastName = lastName;
customerRepository.SaveChanges();

The repository can then be wrapped by a service layer to provide view model objects or DTO's

Isn't that little inefficient ?

Don't prematurely optimise. When you have a performance issue, analyse the performance, identify a cause and then optimise. Repeat.

Update

A repository wraps data access, usually a single entity. A service layer wraps business logic and can access multiply entities through multiple repositories. It usually deals with 'slim' models or DTO's.

An example could be something like getting a list of invoices for a customer

public Customer GetCustomerWithInvoices(int id) {

  var customer = customerRepository.Get(id);
  var invoiceList = invoiceRepository.GetAllInvoicesFor(id);

  return new Customer {
    Customer = customer,
    Invoices = invoiceList
  };

}