Sieve VS dynamic-linq-query-builder

Biarity/Sieve: ⚗️ Clean & extensible Sorting, Filtering, and Pagination for ASP.NET Core (github.com)

I´m trying out Sieve and the rip my app to pieces and use that instead.

Similar to Sieve

https://github.com/Biarity/Sieve Sieve is a simple, clean, and extensible framework for .NET Core that adds sorting, filtering, and pagination functionality out of the box. Most common use case would be for serving ASP.NET Core GET queries.

If you're looking for a library for a REST API, there really aren't very many good ones. I used Sieve as a starting point to write my own because it didn't support the filtering syntax I was required to use. I would definitely not recommend a new person write their own, however.

I also looked at Sieve: https://github.com/Biarity/Sieve but I'm not sure it is 100% hitting what I am wanting. Unless I am just a bork at the end of my day unable to read properly. Any direction in the right area would greatly be appreciated!

For complex queries like this, you don't have a ton of choices. You could use Sieve (https://github.com/Biarity/Sieve) in lieu of your current implementation. I use it specifically in situations to handle filtering/paging/sorting, not as a general way to access data. Most of the time I write an underlying DB view and hook that up to a keyless entity and allow Sieve to do the actual filtering.

If you're using EF, you can use https://github.com/Biarity/Sieve

I ran into this use case a while ago, and I saw a similar inplementation under the jquery UI query builder plugin. https://querybuilder.js.org/. There's an inplementation for .net on the site. https://github.com/castle-it/dynamic-linq-query-builder. Fast foward to today, I no longer use this approach and switched to OData. The backend expose a queryable dataset. Frontend just need to build the querystring to hit the backend Odata api endpoint. I think this approach is much cleaner.