Should I be filtering my IQueryable results from the Domain Service?
For example... My 3 portals (Websites) access the same Domain Service Layer, depending on the type of user it is, I call a specific repository method and return the result,
Current Repository Layer:
IQueryable<Products> GetAllProductsForCrazyUserNow(CrazyUser id);
Products GetAProductForCrazyUserNow(CrazyUser id,product id);
IQueryable<Products> GetProductsForNiceUserNow(NiceUser id);
Products GetProductsForNiceUserNow(NiceUser id,product id);
Would it be best just to do this in the Repository Layer:
IQueryable<Products> GetAllProducts();
Products GetAProduct(product id);
Then within the Domain Service, I simple do the filter i.e.
var Niceman = IQueryable<Products> GetAllProducts().Where(u=> u.Name == "Nice");
NOTE: I have a read only session and session which includes CRUD within the Repository Layer, so please keep that in mind when answering.
Second question: Should I do any filtering at all in the domain service layer? This very layer is the only layer than can amend the Entity i.e. Product.Price == 25.00; This is not delegated to the repository layer.
I think not because the service call to the repository is filtering the records before it get called but I wanted to see what you think. Thanks in advance. I’m not quite sure what you mean. A fat query can get slow when dealing with large datasets.
It took me a little while to really grasp this. The reason is that if a controller needs some data from the database, it can simply use the repository interfaces to get the data. There is no need to go through a service layer for getting data.
First create a Client class in MVC project. Next, we will create an interface in Repository class library project. This interface contains generic database operations for any domain entity. We will name it IRepository. Next, we will create a repository class to implement this interface. We will name this class Repository.
Repository Pattern In ASP.NET MVC. In this article, we will learn about Repository pattern which is mostly used to create enterprise applications. Repository pattern divides application’s UI, business logic and data access components into different layers that are easily maintainable and testable.
I normally use the repository layer to do simple CRUD work and have the domain layer perform any business logic or in your case any filtering that is needed before passing that data back to the UI layer.
Separating out the business/filtering logic from the repository layer will help keep things clean. Also, in the future if you move to a different type of data access pattern, then you won't have to change how that code works since it will be separated in your domain layer.
Haroon,
I use extension methods on IQueryable<Classes>
OUTSIDE of the repo. in fact, i have a set of classes that i call 'Filters' and they are usually something along these lines:
public static class ProductFilters
{
public static IQueryable<Products> NiceMan(
this IQueryable<Products> customQuery, string filterName)
{
if (!string.IsNullOrEmpty(filterName))
customQuery = customQuery.Where(u => u.Name == filterName);
return customQuery;
}
// create lots of other Products based filters here
// and repeat with seperate IQueryable<Classes> per type
}
usage:
var Niceman = IQueryable<Products> GetAllProducts().NiceMan("Nice");
I find this a good separation of logic and keeps the repo clean. And in answer to the second question, yes, use this filter/extension logic inside the service layer, rather than the repo as well.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With