Where does my CRUD LINQ Code Go? ASP.NET MVC

Question

I am currently using the ASP.NET MVC framework on a project (pretty much my first time)

I am using Linq2SQL as my data model..

Where should i have this kind of code:

var entries = from e in db.sometable select e;

I currently have this kinda code in the controller and pass the data i get into the view..

is this ok?

if not how do i entend my linq2sql datamodel to include this kindof code?

Thanks

Daniel

Answer 1

To add what @Poco said, here's an example:

In Foo.Common.Repositories (inside the Foo.Common Project):

public interface IRepository<T>
{
    IEnumerable<T> GetAll();
    void Update(T entity);
    void Add(T entity);
    void Delete(T entity);
    void Save();
}

public interface IUserRepository : IRepository<User>
{
    void GetByCredentials(string username, string password);
}

The inside Foo.Data.Repositories (inside Foo.Data project):

public class UserRepository
{
    // ... other methods/properties snipped.

    public IEnumerable<User> GetAll()
    {
        // Where this.Users would be L2Sql or Code-First... or some other ORM.
        return from u in this.Users orderby u.Name select u;
    }
}

Then inside your actual Foo.Web:

public class UserController : Controller
{
    private readonly IUserRepository userRepository;

    public UserController(IUserRepository userRepository)
    {
         this.userRepository = userRepository;
    }

    [AcceptVerbs(HttpVerbs.Get)]
    public ViewResult List()
    {
        var users = this.userRepository.GetAll();
        return this.View(users);
    }
}

And inside your Global.asax you'd have Ninject or some other IoC container to resolve IUserRepository:

public static void RegisterServices(IKernel kernel)
{
    kernel.Bind<IUserRepository>().To<UserRepository>();
}

protected void Application_Start()
{
    var kernel = new StandardKernel();

    AreaRegistration.RegisterAllAreas();

    MvcApplication.RegisterGlobalFilters(GlobalFilters.Filters);
    MvcApplication.RegisterRoutes(RouteTable.Routes);
    MvcApplication.RegisterServices(kernel);

    // I'm using MVC3 here:
    DependencyResolver.SetResolver(new NinjectResolver(kernel));
}

Answer 2

It's common to use the Repository pattern for MVC. Typically, you define an interface, for instance, IProducts, and then, you implement this interface, calling you linq2sql code. Your controller will accept this interface as a parameter for the constructor, so that it depends on this interface, and not on a concrete class. Using a dependency injector, such as Ninject, will allow you to supply a concrete interface implementation to the constructor. This enables Unit Testing on you web app, and also adds flexibility.

There's a really nice book, Pro ASP.NET MVC 2 Framework, that explains all that. I'm currently reading it, and I just love it.

Answer 3

It's fine to have Linq queries in controller methods.

If we're talking about separation of concerns, the idea is that your data layer (in this case, the repository(?) code that supplies you with db.sometable) decouples your logic code (controller methods in this case) from the datastore.

You query the data layer rather than the database, so you can change the underlying datastore and your controller code will still work.

Some would argue that it's better again to move as much logic code as you can out of the controllers and into your model code (see the first answer here), but it depends how far you want to go.

Answer 4

Here's an example of how to implement the repository pattern

In addition to this I would implement an additional layer to handle your applications business logic and keep your controllers lightweight