ASP.Net MVC & Entity Framework project architecture WITHOUT repository pattern

Question

I'm starting a new small project with ASP.NET MVC and Entity Framework. (SQL Server - around 20 DB tables) In past projects I’ve used Linq2SQL but it seems to be obsolete.

I've read a lot of posts on using repository pattern for EF (pros and cons) , For me it seems better/simpler to code without repository pattern.

I created the following project architecture :

namespace MySite.Models
{
    public class User
    {
        public Int32 ID { get; set; }
        public String Email { get; set; }
        public String Password { get; set; }
        public String Name { get; set; }
        public Int32 Gender { get; set; }
    }
}

namespace MySite.DAL
{
    public class Users
    {
       public static IEnumerable<User> GetUsers()
        {
            using (var context = new DatingSiteContext())
            {
                return context.Users.ToList();
            }
        }

        public static User GetUserByID(int id)
        {
            using (var context = new DatingSiteContext())
            {
                return context.Users.Find(id);
            }
        }
}

namespace MySite.Controllers
{
    public class HomeController : Controller
    {

        public ActionResult Index()
        {
            ViewBag.Message = "Modify this template to jump-start your ASP.NET MVC application.";

            var users = DAL.Users.GetUsers();

            return View(users);
        }
    }
}

What are the disadvantage of using EF like this? (Except lack of unit testing support)
Is it wrong to create a new DbContext on each call to DAL ? Any Performance hit?
Any other recommended structure for using EF ? Examples? :)
Would you use Linq2SQL in a new project ?

Thank you.

Edit:

The code inside GetUsers() and GetUserByID() is just for example , i understand its a bad practice to return all records from the db (paging or filter in missing)

For me your DAL is kind of like repositories just you added the name "Users" instead of "UserRepository" — jannagy02
Keep in mind calling ToList() like you do in return context.Users.ToList(); will return the entire dataset into memory which may take a performance hit if there are a lot of users. — alstonp
FYI, if Linq2Sql works for you, keep using it. It's not going away, it's just not getting any new features. For a small project, you should be fine. Also, EF dbcontexts are intended to be short lived, you can run into problems if you use them in prolonged situations, so yes.. DO create a new one every time you use it. — Erik Funkenbusch

Henk Mollema Henk Mollema · Accepted Answer · 2013-10-17T14:48:49

You actually just created a repository only you call it a 'data access layer' which is, in my opinion, not a good name since Entity Framework is the data access layer. A repository is an abstraction on top of a data access layer, Entity Framework in this case.

Is it wrong to create a new DbContext on each call to DAL ? Any Performance hit?

Nope, it's just fine, but it might cause trouble when you fetch an entity in one instance of DbContext, and try to update it in another instance.

Would you use Linq2SQL in a new project ?

Nope, Microsoft proposed Entity Framework as the successor of L2SQL and active development of it has stopped.

Any other recommended structure for using EF ? Examples? :)

The approach you use, specific repositories, will result in a lot of redundant code. You could create a generic repository implementing an interface:

public interface IRepository<TEntity> 
    where TEntity : class, new()
{
    IEnumerable<TEntity> GetAll();

    TEntity GetById(int id);

    IQueryable<TEntity> Table { get; }
}

And an implementation of this:

public EfRepository<TEntity> : IRepository<TEntity>
    where TEntity : class, new()
{
    private readonly DatingSiteContext _context;

    public EfRepository()
    {
        _context = new DatingSiteContext();
    }

    private IDbSet<TEntity> Entities
    {
        get
        {
            return _context.Set<TEntity>();
        }
    }

    public IEnumerable<TEntity> GetAll()
    {
        return Entities.ToList();
    }

    public TEntity GetById(int id)
    {
        return Entities.Find(id);
    }

    public IQueryable<TEntity> Table 
    { 
        get { return Entities; }
    }   
}

You can use this repository in your controller like this:

public class HomeController : Controller
{
    private readonly IRepository<User> _userRepository;

    public HomeController()
    {
        _userRepository = new EfRepository<User>();
    }

    public ActionResult Index()
    {
        var users = _userRepository.GetAll();
        var inactiveUsers = _userRepository.Table.Where(u => !u.Active).ToList();
    }
}

This generic repository allows you to create mocked repositories:

public class FakeUserRepository : IRepository<User> 
{ 
    // ... 
}

IRepository<>IQueryable<>

I'm not saying this is the best method, just one I use regularly in projects. I have to say that I usually write a business (service) layer between the controller and the repositories. I keep my business logic and complex Linq queries (and their execution) there. I also use an IoC container which handles the lifetime of my objects (instances of DbContext and services for example). See this question for more information about that.

ASP.Net MVC & Entity Framework project architecture WITHOUT repository pattern

3 Answers