Question

I think I’ve hit that “paralysis by analysis” state.
I have an MVC app, using EF as an ORM.
So I’m trying to decide on the best data access pattern, and so far I’m thinking putting all data access logic into controllers is the way to go.. but it kinda doesn’t sound right.
Another option is creating an external repository, handling data interactions.
Here’s my pros/cons:

If embedding data access to controllers, I will end up with code like this:

using (DbContext db = new DbContext())
{
    User user = db.Users.Where(x=>x.Name == "Bob").Single();
    user.Address.Street = "some st";
    db.SaveChanges();
}

So with this, I get full benefits of lazy loading, I close connection right after I’m done, I’m flexible on where clause – all the niceties.
The con – I’m mixing a bunch of stuff in a single method – data checking, data access, UI interactions.

With Repository, I’m externalizing data access, and in theory can just replace repos if I decide to use ado.net or go with different database.
But, I don’t see a good clean way to realize lazy loading, and how to control DbContext/connection life time.
Say, I have IRepository interface with CRUD methods, how would I load a List of addresses that belong to a given user ? Making methods like GetAddressListByUserId looks ugly, wrong,
and will make me to create a bunch of methods that are just as ugly, and make little sense when using ORM.

I’m sure this problem been solved like million times, and hope there’s a solution somewhere..

---

And one more question on repository pattern – how do you deal with objects that are properties ? E.g. User has a list of addresses, how would you retrieve that list ? Create a repository for the address ? With ORM the address object doesn’t have to have a reference back to user, nor Id field, with repo – it will have to have all that. More code, more exposed properties..

Answer 1

The approach you choose depends a lot on the type of project you are going to be working with. For small projects where a Rapid Application Development (RAD) approach is required, it might almost be OK to use your EF model directly in the MVC project and have data access in the controllers, but the more the project grows, the more messy it will become and you will start running into more and more problems. In case you want good design and maintainability, there are several different approaches, but in general you can stick to the following:

Keep your controllers and Views clean. Controllers should only control the application flow and not contain data access or even business logic. Views should only be used for presentation – give it a ViewModel and it will present it as Html (no business logic or calculations). A ViewModel per view is a pretty clean way of doing it.

A typical controller action would look like:

public ActionResult UpdateCompany(CompanyViewModel model)
{
    if (ModelState.IsValid)
    {
        Company company = SomeCompanyViewModelHelper.
                          MapCompanyViewModelToDomainObject(model);
        companyService.UpdateCompany(company);
        return RedirectToRoute(/* Wherever you go after company is updated */);
    }
    // Return the same view with highlighted errors
    return View(model);
}

Due to the aforementioned reasons, it is good to abstract your data access (testability, ease of switching the data provider or ORM or whatever, etc.). The Repository pattern is a good choice, but here you also get a few implementation options. There’s always been a lot of discussion about generic/non-generic repositories, whether or not one should return IQueryables, etc. But eventually it’s for you to choose.

Btw, why do you want lazy loading? As a rule, you know exactly what data you require for a specific view, so why would you choose to fetch it in a deferred way, thus making extra database calls, instead of eager loading everything you need in one call? Personally, I think it’s okay to have multiple Get methods for fetching objects with or without children. E.g.

public class CompanyRepository
{
    Get(int Id);
    Get(string name);
    GetWithEmployees(int id);
    ...
}

It might seem a bit overkill and you may choose a different approach, but as long as you have a pattern you follow, maintaining the code is much easier.