You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In clean architecture (DDD specifically), it's common to encapsulate your domain layer.
It should not have external dependencies (thus, no attributes, which are ugly either way, though)
The behavior itself is encapsulated, so instead of properties, we use private fields which can be changed only via publicly exposed methods that resemble domain logic
Before adding this library to the project, I thought the Field class was made specifically for that. But now it seems that it's not. It either doesn't work with fields or just doesn't pick up private ones.
Tell me, please, do I miss something obvious, or it's not possible to use the full-ORM side of RepoDb if all of my classes contain only private fields?
No, this is not possible. The hydration process onky succeed with columns projection to those writeable class properties or constructor parameters (with the same name as underlying table field).
As there are projections defined on the ctor arguments during hydration, therefore, I would expect that this would work if the underlying table has the FirstName and LastName columns.
In clean architecture (DDD specifically), it's common to encapsulate your domain layer.
Before adding this library to the project, I thought the
Field
class was made specifically for that. But now it seems that it's not. It either doesn't work with fields or just doesn't pick up private ones.Tell me, please, do I miss something obvious, or it's not possible to use the full-ORM side of RepoDb if all of my classes contain only private fields?
Basic example:
I tried mapping like this (which is not perfect, but it'd be ok if it worked), but it doesn't work:
The text was updated successfully, but these errors were encountered: