• Coding
  • ASP.NET MVC and the Repository Pattern

Hey everyone,

I'm not really sure about my information but what I know is that when using the repository pattern, the filtering should happen right after the Data Access layer (which is in most cases a code library project). In this case, the structure of the solution would be:
1. Code library for the repositories and all the business logic.
2. An ASP.NET MVC Web Application where all the view logic takes place.
3. (Optional) Unit Testing Project (which I am not using).

But I've seen (on some blogs) that some developers separate the data access/repositories from the business logic, so they create another code library projects which is called "Services" which takes care of all the business logic and filtering of data (usually using Extension Methods on IQueryable<T>).

Which structure do you think is more reasonable? Does it really make sense to create the Services code library?
You should definitely split your repository from your business logic. Regardless, your DAL/BL both are within your model. The reasoning behind this is mostly due to loose coupling, which is one of the main reason why MVC exists. The other reason is that when you're using the repository pattern you're not necessarily saying that you're using a DB as a back-end. You separate your back-end from your BL by merely injecting a repository into your BL, thus allowing Mocking frameworks to help you with your unit tests. Furthermore, you can reuse your existing model project elsewhere without having to incorporate business logic that you really don't need in your other project.