vkhorikov / SpecificationPattern

Implementation of the Specification Pattern in C#
301 stars 72 forks source link

OR-Mapper dependency in your domain logic #3

Open medoni opened 1 year ago

medoni commented 1 year ago

First of all, I would like to thank you for the very good articles on your site enterprisecraftmanship. These articles helped me very much understanding and implementing DDD. Thanks for that ❤️

I have „problems“ with your GetRealType() - Method on every Entity. This adds a very hard dependency to your Domain Logic for every Entity. I think in DDD the domain logic must not know anything about the underlaying database.

But I also know why this is needed when using OR-Mapper. Currently I‘m facing same issues with EF Core (7) using transparent proxies.

In my opinion the OR-Mapper should provide a why of proxying single properties without the need of inheritance.

For example the OR-Mapper could create transparent proxies for IList, ISet or implement an ILazy for referencing other entities with foreign keys.

What do you think?

https://github.com/vkhorikov/SpecificationPattern/blob/15086389101fc296e67d6d76102b611d40775b2b/SpecificationPattern/Entity.cs#L59

vkhorikov commented 1 year ago

Yes, this is a clear diversion from an ideal separation of concerns, similar to marking properties as virtual in domain classes due to lazy loading. But that's a worth-while trade-off in my opinion, because it doesn't change the behavior of your domain classes (they behave the same way with and without an ORM) and also because the alternative (not having an ORM) means you must write much more code, making the overall solution less maintainable.

Here's the latest version of Entity I use:

https://github.com/vkhorikov/CSharpFunctionalExtensions/blob/master/CSharpFunctionalExtensions/Entity/Entity.cs#L24 https://github.com/vkhorikov/CSharpFunctionalExtensions/blob/master/CSharpFunctionalExtensions/ValueObject/ValueObject.cs#L106-L118