Materializing objects inheriting from DynamicObject

[walkindude]

A few days ago I found myself in the need to use Query<T> with an object inheriting from DynamicObject.

Currently, as per @mgravell's kind answer, this is not supported. He suggested I open an issue so you guys can take a look.

All references to my use case are detailed in my StackOverflow question linked above, along with a brief and by no means complete exchange of opinions as to how this could be handled.

Basically, the constructor for DefaultTypeMap (going from memory here, the names could be wrong) is quite PropertyInfo-centric, which would probably need to to be changed to also look at T and whether it implements IDynamicMetaObjectProvider.

The suggestions were to support DynamicObject-derived objects both for materializing and as parameters, hence:

• probing for IDynamicMetaObjectProvider
• allowing use of such objects as parameters, with the limitation that they have to provide an override for GetDynamicMemberNames()

[mgravell]

Yep, fully agree this is something we should support. At the moment, due to time reasons (rc1, etc), a lot of my time is devoted to core-clr conversions. Dapper is already deployed on core-clr rc1, but I have a few other libraries to get switched over. I'm just trying to set expectation that this isn't something I can start on this week!

On Sun, 22 Nov 2015 16:12 Stefano Mioli notifications@github.com wrote:

A few days ago I found myself in the need to use Query with an object inheriting from DynamicObject http://stackoverflow.com/questions/33799503/materialize-object-inheriting-from-dynamicobject-with-dapper .

Currently, as per @mgravell https://github.com/mgravell's kind answer http://stackoverflow.com/q/33799503/129782, this is not supported. He suggested I open an issue so you guys can take a look.

All references to my use case are detailed in my StackOverflow question linked above, along with a brief and by no means complete exchange of opinions as to how this could be handled.

Basically, the constructor for DefaultTypeMap (going from memory here, the names could be wrong) is quite PropertyInfo-centric, which would probably need to to be changed to also look at T and whether it implements IDynamicMetaObjectProvider.

The suggestions were to support DynamicObject-derived objects both for materializing and as parameters, hence:

• probing for IDynamicMetaObjectProvider
• allowing use of such objects as parameters, with the limitation that they have to provide an override for GetDynamicMemberNames()

— Reply to this email directly or view it on GitHub https://github.com/StackExchange/dapper-dot-net/issues/406.

[NickCraver]

+1 on supporting this. I have a massive changeset now that finishes porting Dapper over to CoreCLR (everything - including Contrib and tests), it should be easier to make changes after that's in - eliminating the 2nd solution as well. Working the last 41 tests which have some fun properties then PR incoming.

[walkindude]

I apologize for this little OT, but I wanted to thank you guys: @mgravell, @NickCraver and all the other contributors for the effort you put into this project: it really is the best library I ever worked with, hands down. I feel like Dapper is treating me like a human.

Again, thank you all so much :pray:

[racekarl]

It's been four and half years since this issue was originally raised, so I just wanted to check in and say that in 2020 this ability would still be appreciated. I really appreciate the speed and ease of use of Dapper and heartily echo the previous comment - this really is a great library and I would love to use it in my new project.

Here is my use case, in case it helps:

Our system is used to manage a variety of entities that all have a few properties in common (think geospatial: every entity has a location and a shape) but then each one has a different range of attributes that are stored for it. The pain point for us is that each implementation has a different set of entities and tracks a different set of attributes for each one, and these entities and attributes change relatively frequently.

We need to to some calculations using the common properties across all entities, for example: "How far is this valve from that facility?" but then we also need to retrieve all of the specific attributes for a given type of entity. Because of the pace of change of the entities and attributes, it would be impractical for us to create and maintain dedicated model objects for each entity.

What would be great is if we could create a type which inherits from DynamicObject, but also implements an interface which defines the common properties (location and shape). If I could pass this type to Dapper and have it populate both the existing interface-defined properties as well as add dynamic properties I could then pass these objects to my calculator methods using the interface, as well as return the whole object to display all its attributes on screen