Domain Entity Type Mapping - part two, now with less swearing!
In this session, I describe the DomainEntity to IdiomaticType concept.
In my head, I have the idea that a DomainEntity is an abstract concept that's represented by various different classes that exist within my application's components.
Until now, whenever a component exchanges an instance of a class with one of its dependencies, I've had to manually write code to convert between the "Local Type" and the Type declared by the dependency that owns it. This is a pain in the neck.
Why not create some way to decorate these "Local Types" with some kind of identifier that associates the Type and (some or all) of its Properties with that overarching (ABSTRACT) Domain Concept? And how would I do that without increasing the coupling between those components?
I've added a couple custom .Net Attributes to my Architectural Framework project. I added some organized collections of string constants to the Application's framework project, and then a little Utility class in the architecture project that reads those attributes from the classes, and with a bit of System.Reflection magic, converts one to the other without any manual mapping code.
Yes, I know... I've reinvented [insert Mapping package here] but frankly, I don't like any of the ones I've used in the past, and for things like this, I want to own the code that performs this critical function. So here we are.
As of this video, I can now transfer simple property values between "equivalent" models of the same Domain Concept with a single line of code. We'll get fancy over the next couple sessions.
Until next time, Happy Coding!
thatDeveloperDad
-- The repo for the system-framework (ThatDeveloperDad.iFX) is at: https://github.com/ThatDeveloperDad/s...
— The GitHub repo for my SaaS Admin project is here: https://github.com/ThatDeveloperDad/T...
— Music by Karl Casey @ White Bat Audio
-- Watch live at / thatdeveloperdad