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?
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?