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)

Answer 1

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> 
{ 
    // ... 
}

---

This approach might seem like a lot of code, but as your entity type amount grows, it will save you a lot of work since all you have to do is create an IRepository<> field in a controller. Yet you have a lot of flexibility with the IQueryable<> property which allows deferred execution.

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.

Answer 2

My thoughts

Whats the disadvantages:

• You cant really unit test anywhere that uses the static methods you have defined in your DAL.
• They are also strongly coupled making them more difficult to swap out at runtime, if that became a requirement.
• You may start to get additional complications if you need to commit several updates in a transaction

Is it wrong to create a new DbContext on each call?

• No, this is fine. The DbContext is lightweight and meant to be used this way.

Other patterns

• You already mentioned the repository pattern which is pretty solid, especially when used with a unit of work pattern.

Would you use Linqtosql

• No - Linqtosql is pretty much done with, entity framework provides a more complete and generally better solution to this problem