Adding support for Projections

[davidjamesb]

Hi. Thanks for your work on this great library.

Are there any plans to support Projections alongside Filtering and Ordering?

This feature would be similar to the $select query string parameter from ODATA - where a subset of fields are returned and would most likely involve transforming the selected fields into an expression that can be passed to the Select(x=>) on the IQueryable being Gridify'd.

I have implemented something similar in the past for transforming the fields selected within a GraphQL query into expressions that can work with LINQ.

I haven't had time to inspect the codebase and draft a PR but just wondering if there were any thoughts around the viability of bringing this functionality to this library?

[alirezanet]

Hi @davidjamesb,

I've been thinking about this feature for a long time, but in most projects, it's not needed directly within Gridify. Currently, you can achieve the same behavior by combining Gridify with other libraries like AutoMapper or Mapster. You can find an example here.

That said, I might consider adding a projection feature in the next major version of Gridify. The challenge is that projection aligns more with GraphQL-style queries rather than structured queries with a known return type. Implementing it would require significant breaking changes, which can only be introduced in a major release.

Let me know if you have any thoughts or alternative approaches!

[davidjamesb]

Hey @alirezanet.

I had a quick play with the codebase to see how to implement projections natively, without requiring any additional mapping libraries. The main motivation is to be able to accept a 'select' query string parameter from an incoming REST API call to prevent loading all fields from the underlying database query.

It's quick and dirty and mainly as an exercise for myself but I've created a branch in my fork here:
/~https://github.com/davidjamesb/Gridify/tree/spike/projections

I've added a few unit tests under the "ApplyProjection" region within GridifyExtensionsShould.

[alirezanet]

Hi @davidjamesb,

It looks good! However, the return type of the projection seems to be the first challenge. I assume the goal is to ultimately get a dynamic type, right?
Also, looking at your tests, you projected only the id field, but you were still able to access the name property, which doesn’t seem correct (unless I’m missing something).
Once you feel you have a reasonable implementation, feel free to open a PR so we can discuss it in more detail there.

[davidjamesb]

In the first iteration that I added - the projected type was the same as the 'source type' e.g. IQueryable<T>.ApplyProjection(..) will return an IQueryable<T>.

However it will only fill in values for the members that have been specified in the select clause in the GridifyQuery. The rest are set to their default values. This means you can use the same result model as the source whilst still only retrieving a subset of fields from an underlying database call - leading to more efficient database queries. So naturally, TestClass.Name would still be accessible if only selecting id as it's part of the static type definition for TestClass, but it won't have a value populated as it wasn't retrieved from the underlying query call.

I have just added a more usable version (same branch) which adds ApplyProjection<T, TResult> which allows you to specify the type of the projected model - so you can specify a cut down version with some subset of members that exist in T. This is the more natural case for how projections would be used and is similar to how the existing AutoMapper functionality would be used:

There are a few caveats though - the approach is a bit 'dirty' as you can see that my ApplyProjection<TResult>() implementation loses the use of the TSortingQuery generic type and constrains TResult to require a parameterless constructor. A bit of refactoring around the generic signatures of the builder classes would hopefully resolve that.

Again, this is just my first initial implementation messing about with Expressions and looking for the extension points in the library and you may feel this isn't the right approach / you can see some flaws in adding this functionality into the base library, but it's an interesting exercise and something I'll be looking to implement as an optimization to my existing REST APIs.

It was either extend Gridify, nest Gridify inside another component (and re-use the mapper/expression builder logic that exists within Gridify to handle Select) or go the full way and move to ODATA/GraphQL. I prefer the first or second approach :)

[alirezanet]

Ideally, I'd like to let users choose between different projection types:

-Projecting to the same return type with empty values
-Specifying a new type for projection
-A simplified GraphQL-like approach, returning a dynamic/anonymous object

But in all cases, I think GridifyMapper should remain the core component for configurations.