search

CollaboratingPlatypus / PetaPoco

Official PetaPoco, A tiny ORM-ish thing for your POCO's
Other
2.07k stars 601 forks source link

Complex object materialization #263

Open enrico-padovani opened 8 years ago

enrico-padovani commented 8 years ago

Hi,

I understand how to manage complex object materialization by using a custom object relator class. But I recently tried a very small and focused library "Slapper.AutoMapper" and the way you can achieve this is very effective, so I wanted to report it.

I've also tried it combined with petapoco dynamic query projections and it works (not particularly fast but you pay some price on complex scenarios I guess)

It's all based on conventions on column names and it's also extensible (for ex. you can replace the custom attribute Id with your own)

So, maybe it's an idea to add complex object materialization to petapoco! I think it will be a very nice to have feature.

Thanks, Enrico

pleb commented 8 years ago

Updated your comment to link to library.

The library itself is very interesting and I like how easy the usage is.

I've been playing around with how to populate/persist related entities. I'm still mulling over ideas in my head, because nothing so far aligns with PetaPoco's simplicity and ease of use.

Do you see this as a query only feature (read only)?

Can I ask how you're currently persisting related pocos?

enrico-padovani commented 8 years ago

I think PetaPoco should remain simple as you said. Right now I'm trying to run away from EF and friends and kinda go back to the roots.

I'm just testing out possibilities, but I see this as a read-only feature. If you try to persist a graph of entities I think you'll end up in complex mapping and you'll still have headaches figuring out.

Recently I see applications really divided into queries and write commands as separate worlds like in CQRS, especially in web apps where you have disconnected entities.

In the tests I'm doing with this library, I'm persisting related entities basically with forech into a transaction, so by hand.

Said that, as a first step I'd introduce this convention based read-only feature (maybe configurable) as an addition to the current object materialization. You can easely try now to combine PetaPoco dynamic result as an input for Slapper and it will materialize all in a proper way. I guess those two libraries shares the simplicity principles.