POCO One-To-One, micro ORM. Should I store ref id or only ref object?

dapper domain-driven-design micro-orm poco repository

Question

Should I store ref id to child Poco or only ref object in Model when using micro ORM like Dapper (in Repository)? I think that if I store both there will be synchronization issue when updating root object.

For example:

Class Boat
    +Id
    +LakeId
    +Lake

Class Lake
    +Id
    +Name

What If some changes LakeId ? Lake will be in invalid state! What if someone changes Lake and live LakeId? LakeId will be in invalid state.

I thing that synchronization of those two properties will be an additional unnecessary complexity. Changing LakeId will require to get new Lake poco from db.

How do you deal with this in your projects (only using micro ORM like Dapper or PetaPoco)?

Popular Answer

Any micro orm is just a data mapper on steroids. It doesn't care what sql you write, it just tries to map the query result to an object. Any insert/update helpers just make it easier to do that operation without messing with sql.

Your concerns have nothing to do with the micro orm. You simply have to put a foreign key constraint on LakeId. I don't really understand why you have both LakeId and Lake in Boat. You need to get the db schema straight first, then the object (POCO) you need for mapping the query result.



Licensed under: CC-BY-SA with attribution
Not affiliated with Stack Overflow
Is this KB legal? Yes, learn why
Licensed under: CC-BY-SA with attribution
Not affiliated with Stack Overflow
Is this KB legal? Yes, learn why