Open davidhenley opened 1 year ago
Good point. APIs are not my forte (but most definitely Steve's!) and this is not the course for learning how to build them. I like the service that knows how to call the sprocs. Maybe spec on TOP of that? Not sure if you watched the course but I did recommend that library and the full blown use of it in the DDD course that Steve and I built together. I'll experiment with it but can't update the course.
Hey @davidhenley . Thanks for the inspiration. Becuse of the complexity of the model, I still don't believe using LINQ and the wonderful EF Specification library is feasible. However I came up with a cool solution that you inspired. I really pushed myself. In the end I have a much more complicated stored proc that allows combining filters (but can't do it dynamically). The service call to that is a single call that leverages a filter class. And there is a single point of entry into the service class. This is the "FLEX" version of the service and UI in this repo: https://github.com/julielerman/FilteringwithEFCoreandDDD/tree/searchcontextlite
Just curious as to why you created the search section this way, as it doesn't seem like the best path to go down.
The ContractSearch section (Module 10, Lessions 6-7) is making clients call different API paths for different search parameters.
The searching would be better handled using one path with query params and something like
Ardalis' Specification
library or a manually built EF query or SP, so that you don't have to call/firstName
/lastName
/firstName/lastName
,dateRange
etc.Something like this: