Why enforce type constraint at the class level?

[mikebeaton]

Issue raised on medium.com:

Hi Mike, Looks like a promising Micro-Orm and I’ll be sure to try it, but may I ask why you enforce a type constraint at the class level rather than allowing people pass in the return type as an parameter?

Query result objects are quite often specific to the query or stored proc, and having to inject an instance of MightyOrm class each query return type seems a bit laborious.

It was something I never understood about Dapper.MicroOrm.Repositories either, given that under the hood all methods are invoking a protected method with the class type argument.

If there is a good reason, might I suggest allowing people to optionally override the result type my passing the method a type argument?

[mikebeaton]

My response:

The short answer is: that’s how Massive worked, and my aim was to write a compatible library. Even though I’ve added strong typing, Massive was written to encourage creating new instances ad hoc as required and each given instance’s table-specific commands were tied to a given table, as in Mighty.

As a slightly longer answer, I wonder if you might possibly be looking for this piece of info from Stack Overflow: “Generic repository in ASP.NET Core without having a separate AddScoped line per table in Startup.cs?”

Also, look out for version 4 of Mighty where .ResultsAs will move from the work-in-progress code branch to the release NuGet package. You could use that feature to do what you specifically want. Though with the generic injector pattern, maybe you won’t need to.

[mikebeaton]

OP's response:

Thanks for your reply. The generic repository pattern works pretty well for typical CRUD operations on tables but executing stored procs or more complicated queries can can become a bit of a pain point, but the ResultsAs method on the mighty API seems to solve that quite elegantly.

Thanks I will be sure to put your library to use.