Implementing Integrations as separate types #441
Closed
Nikira2023
started this conversation in
Ideas
Replies: 2 comments
-
Hi, thanks for feedback. Apologies for the extremely long delay in replying - for some reason, this didn't show up in my notifications. I'll hopefully get around to looking at this shortly. I can certainly understand not wanting to include such dependencies if the domain layer. |
Beta Was this translation helpful? Give feedback.
0 replies
-
This has now been implemented. Thanks for your feedback! |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
I love this library (Thank you) - I'm just itching to use it everywhere! However (and apologies if this is already possible) I hit a snag on a PoC as follows:
I have a 'DataObjects' class library that holds all of my POCO classes, enums etc. and now Vogen ID types; then I have a separate DataAccess class library that contains the Dapper implementation around those POCO classes.
Now if add a Dapper integration to each of my Vogen types then I'm forced to add a Dapper dependency to my DataObjects library (which then adds a dependency all the way through my business logic which, until now, was completely db agnostic).
What would be nice would be to carry on building Vogen Id types as at present, but then in my DataAccess library build the integrations, so something like:
[VogenDapperIntegration(typeof(MyRecordId))]
partial class MyRecordIdDapperTypeConvertor {}
Beta Was this translation helpful? Give feedback.
All reactions