You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
These few days I dedicated some time to specifications, and I want to elaborate one more idea/feature. Then I finally have to get back to my real work :)
The usage (as it is for now), is quite straightforward for retrieving data from DB. You instantiate a specification, pass it to a repository method and that's it.
But, if you need to apply the specification to some collection that you already have in hand, then the usage is a bit tricky. Let's examine this example that you might have in some of your services
var spec = new CustomerSpecification(customerID);
var evaluator = new SpecificationEvaluator<Customer>();
var result = evaluator.GetQuery(SomeCollectionOfCustomers().AsQueryable(), spec).ToList();
This, at best looks ugly. First of all, the evaluator lives in the plugin package (in infrastructure project), so you won't be able to reference it here directly. You actually have to inject the ISpecificationEvaluator in the constructor, and work with that instead. And that means you have to wire up them in you IoC container. The next issue is that SpecificationEvaluator also will try to evaluate EF related IQueryable extensions like Include, Like etc. An in this scenario, that will throw an exception. And lastly, the usage is just complicated, too many conversions done by hand.
Suggestion:
The base package will have its own specification evaluator, which instead of operating on top of IQueryable, will operate on IEnumerable/List. And it will evaluate only standard operations (excluding Include, Like).
We should name this evaluator with distinct name, so it can be obvious that if specification contains Include or Like, they will be omitted during this evaluation.
Finally, the specification internally will hold an instance of this evaluator, and will expose the evaluation functionality through a public construct.
So, the usage would be something like:
var result = new CustomerSpecification(customerID).Evaluate(SomeCollectionOfCustomers);
I think this is much more clear, and will improve the usage of specification in these scenarios.
The Evaluate() method should have some better name to make it clear that some stuff are excluded.
The text was updated successfully, but these errors were encountered:
These few days I dedicated some time to specifications, and I want to elaborate one more idea/feature. Then I finally have to get back to my real work :)
The usage (as it is for now), is quite straightforward for retrieving data from DB. You instantiate a specification, pass it to a repository method and that's it.
But, if you need to apply the specification to some collection that you already have in hand, then the usage is a bit tricky. Let's examine this example that you might have in some of your services
This, at best looks ugly. First of all, the evaluator lives in the plugin package (in infrastructure project), so you won't be able to reference it here directly. You actually have to inject the ISpecificationEvaluator in the constructor, and work with that instead. And that means you have to wire up them in you IoC container. The next issue is that SpecificationEvaluator also will try to evaluate EF related IQueryable extensions like Include, Like etc. An in this scenario, that will throw an exception. And lastly, the usage is just complicated, too many conversions done by hand.
Suggestion:
So, the usage would be something like:
I think this is much more clear, and will improve the usage of specification in these scenarios.
The
Evaluate()
method should have some better name to make it clear that some stuff are excluded.The text was updated successfully, but these errors were encountered: