Generics as a property

[EvanHennisAtMicrosoft]

I would like to be able to set the generic class as a property on a class.

Ex:

public class CustomModel {
  public string ApiEndpointKey {get; set;}
  public [Class Name] DatabaseModel {get; set;}
  public [Class Name] BusinessModel {get; set;}
}

In this class, I would be able to set the key to my relationship, the database model, and the business model. This would allow me to have a collection of these that I could use to handle conversion from the database to the model.

I could then create all of the relationships for each of my endpoints like this:

Dictionary<string,CustomModel> dict = new();
dict.Add("GetPerson", new CustomModel(){ ApiEndpointKey = "GetPerson", DatabaseModel = PersonTbl, BusinessModel = Person}); 
dict.Add("GetPet", new CustomModel(){ ApiEndpointKey = "GetPet", DatabaseModel = PetTbl, BusinessModel = Pet}); 
...

I would then be able to do something like this:

val relationshipClass = dictionaryForApi<"SomeString">;

val retVal = ConvertModels<relationshipClass.DatabaseModel,relationshipClass.BusinessModel>(primarykeyvalue);

Having this ability would allow me to abstract out a bunch of busy work setting up the wiring. In my real world example, I have 120+ endpoints that are fairly similar outside of the EF class and the business model. But, because I can't do this, I have to create another custom class that has the conversion method as a delegate so that I can set the generics.

I hope this make sense, if not please reach out to me and I can show you (if inside MSFT) what I am working with.

[HaloFour]

Wouldn't the properties be of type Type? I'm not really sure what this is looking to accomplish, or what can be achieved here using generics and static typing.

[EvanHennisAtMicrosoft]

In my scenario, I have 100 database tables and 100 models that line up with 100 endpoints. All of the code outside of the actual conversion from database to model is the same (OData filters, authorization checks, etc. are all the same across the 100 endpoints). I don't currently have a way to link the database class with the model class so that I can call my conversion code like ConvertData<DbClass,ModelClass>(val). If I could create a class that would link the tables, I could have all of my boilerplate code in a single method and then just create the custom conversion code. I can't do this with Types that I know of.

[HaloFour]

You can't resolve generics like that at runtime, short of manually writing reflection. If you were to do it via reflection, you would be working with the Type instances for the business models and database models.

This sounds like a good use case for source generators, that can scan the project and emit a class that contains all of the code that does this boilerplate wiring up.

[EvanHennisAtMicrosoft]

I don't have enough knowledge to know the consequences of having to generate these at runtime. But I assumed it was significant enough that we don't already have a way to do it.

My current workaround is to create the entire method call instead of just keeping the class names:

``
public class CustomModel {
public string ApiEndpointKey {get; set;}
public Func<ValueTask> ConvertToModel<[EF Class Name], [Model Class Name]>{ get; set;}
}

I hate how it looks and really takes away of the clean look and feel that my service class should have.

[En3Tho]

@HaloFour I believe the point here is to register some statically typed mappers to a const dictionary which has string keys.

When you access dictionary by const key you get this typed model.

I think this is something that is possible to do in TypeScript because generics are stripped down and you only have type "hints".

What I don't get though is why dictionary and not just a class with lots of properties?

Also, why not just use normal generics? On your example you have types initialized beforehand.

You still have to manually initialize them in the end (as in example with .Add calls)

[EvanHennisAtMicrosoft]

My issue is that I have 100+ of these and the scale is what is causing me fits. Ideally, here is what I want me service method to look like:

public ValueType<object> GetData(string endpoint) {
  // Check permissions
  // Check authorization
  // Handle OData skip, top, nextlink, etc.
  var mapping = dict[endpoint]; //This is my mapping that has endpoint, EF class, and Model class
  var qry = context.Set<mapping.EFClass>.Where( filter ).Convert<mapping.ModelClass>();
  return qry.ToList();
}

In this flow, I can keep all of my service logic/processing in a "clean" method. I would then just have to create the extension method to handle Convert.

On top of that, there are 2 or 3 other places that I would like to know the connection between the EF class and the model class.

[HaloFour]

Without knowing a lot more about the project it's hard to recommend a particular concrete solution, but there are certainly options. From an API point of you, you could define CustomModel as a generic type with the data and business model types as generic type parameters. They would extend a non-generic base class or interface so that you can store them within the dictionary. Internally, the CustomModel type would use generics to handle the mapping:

public interface EndpointMapping {
    IEnumerable<object> Query(DbContext context);
    Type entityModel { get; }
    Type businessModel { get; }
}

public class CustomModel<TEntity, TBusiness> : EndpointMapping {
    public Type EntityModel { get => typeof(TEntity); }
    public Type BusinessModel { get => typeof(TBusiness); }

    public IEnumerable<object> Query(DbContext context, string filter) {
        return context.Set<TEntity>()
            .Where(filter)
            .Convert<TBusiness>();
    }
}

// add to dictionary:
dict.Add("GetPerson", new CustomModel<PersonTbl, Person>());

// use
EndpointMapping mapping = dict["GetPerson"];
return mapping.Query(context, filter).ToList();

There's obviously a lot missing there, but I think that illustrates ways in which you can achieve the kind of mapping you want without relying on the features of dynamically-typed languages.

Alternatively a lot of the boilerplate kinda stuff could be managed via source generators or reflection. I've used the latter in projects many years ago that would scan assemblies in the current project for custom attributes that would signify EF entities and other attributes that would indicate their relationship to domain objects, etc.

[EvanHennisAtMicrosoft]

I tried a couple of different ways to get the code to feel cleaner and they would fail for one reason or another. In your current case, I didn't want the Query code to be inside the model class. There was something else that was wrong. I would have an "aha" moment only to run into an issue.

I will keep messing with this and see if there is something else I can do.

Thanks for all the comments.

[HaloFour]

Seems like an arbitrary restriction. I see it more as a router or mapping class anyway, and putting business logic in there should be totally fine since it remains separate from the data and domain models. Either way, those guidelines are intended to make your code more manageable. If you have to jump through hoops and write gnarly code in order to adhere to those guidelines you've kind of defeated the purpose, in my opinion. LINQ is an inherently generic API, attempting to negotiate it without generic type arguments will be a nightmare of reflection. Even if the language were to provide a feature, it would be based on that same reflection and be extremely slow and brittle.

[En3Tho]

Yeah I know this feeling of striving for the "clean" or "beautiful" look of your code. The problem is usually "next time".

Ending up writing hacks and lots of magic which seem totally understandable in the moment can look like a total pile of crap next time you look at it and cause questions like "why the hell this is so complex, it's just a mapper?"

With time I learned to see "dumb stupid code" as sort of clean too.

I wish you find the ideal way you want your code to look/feel but if there isn't such then I'd suggest picking a simple one. Future you (or maybe someone else) will appreciate the simplicity.

By the way, source generators might really help you with this. It's worth a shot learning using those if you still haven't.

[theunrepentantgeek]

I've written code very much like this in the past - though it was using NHibernate, not Entity Framework - and I managed to do so without using reflection.

FWIW, here's a recreation of the approach that I took ...

Define an interface representing a mapping:

public interface IModelMapping
{
    string ApiEndpointKey { get; }
    Model Convert(Table t);
}

Table and Model are base classes or interfaces.

and an abstract class implementing that interface:

public abstract class CustomModel<T, M> : IModelMapping
    where T : Table
    where M : Model
{
    public abstract string ApiEndpointKey { get; }

    Model IModelMapping.Convert(Table t)
    {
        return Convert((T)t);
    }

    public abstract M Convert(T row);
}

The explicit interface implementation converts types, and in "real world" code would do some checking to throw a useful exception if misused.

Then define a PersonMapping class to do the conversion from PersonTbl to Person. Ditto for PetMapping. Here you have a natural place to write your conversion code.

public class PersonMapping : CustomModel<PersonTbl, Person>
{
    public override Person Convert(PersonTbl row)
    {
        // ...
    }
}

public class PetMapping : CustomModel<PetTbl, Pet>
{
    public override Pet Convert(PetTbl row)
    {
        // ...
    }
}

Initialization of your dictionary is easy:

Dictionary<string, IModelMapping> dict = new();

void Add(IModelMapping mapping) => dict.Add(mapping.ApiEndpointKey, mapping);

Add(new PersonMapping());
Add(new PetMapping());

And consumption pretty much fits your original brief:

public ValueType<object> GetData(string endpoint)
{
    // Check permissions
    // Check authorization
    // Handle OData skip, top, nextlink, etc.
    var mapping = dict[endpoint];
    var qry = context.Set<mapping.EFClass>.Where(filter).Select(r => mapping.Convert(r));
    return qry.ToList();
}

Based on the thread to date, it doesn't seem (to me) that you actually need a language feature to solve your specific problem.

One last point - some interesting pivots can be achieved by putting an instance into a dynamic variable and then calling the method you know exists.

You could then just write your conversion methods as:

public class PersonMapping : CustomModel<PersonTbl, Person>
{
    public Person Convert(PersonTbl row)
    {
        // ...
    }
}

And then call it as follows:

public ValueType<object> GetData(string endpoint)
{
    // Check permissions
    // Check authorization
    // Handle OData skip, top, nextlink, etc.
    dynamic mapping = dict[endpoint];
    var qry = context.Set<mapping.EFClass>.Where(filter).Select(r => mapping.Convert(r));
    return qry.ToList();
}

In this case, runtime dynamic dispatch calls the method you want, easy as.