ContractSearch should be handled using Specification library or similar

[davidhenley]

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:

public record ContractSearchParams
{
    public string? FirstName { get; init; }
    public string? LastName { get; init; }
    public DateTime? RangeStart { get; init; }
    public DateTime? RangeEnd { get; init; }
}

[julielerman]

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.

[julielerman]

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