-
Notifications
You must be signed in to change notification settings - Fork 52
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Avoid "Default Constructor Dependency" #6
base: master
Are you sure you want to change the base?
Conversation
Aggregate state with an approach that uses constructors like TAggregate(TEvent initEvent) and invokes them through reflection
Thanks for this PR. I have not worked in .net land for quite a bit and for me to merge this would probably be quote the time investment. I may get to it, but probably not soon. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You should probably add .idea
to the .gitignore
file in the root directory, and then remove the .idea
directory & its six (6) files from your PR.
I haven't worked with that IDE much, but it seems like it's similar to .vs
in that it's user-specific configuration info that doesn't belong in the repository.
Why is the default ctor requirement a problem? It's the simplest ctor to use. IMHO handling the first event of a series/stream of events as a special case only adds complexity to the code. |
In the README you wrote I hate the default constructor dependency needed to build Aggregates and Process Managers in the IRepository. I am not sure how to remove it :(.
I have tried removing it, handling first event of stream as a "special case" on rebuilding aggregates: I use (by reflection) a constructor with a signature like
TAggregate(TEvent initEvent)
, constructor I use in the factory static methodCreate
, too.I tried an alternative approach, providing rebuilding functions of the form
TEvent --> TAggregate
and providing explicit rebuilders registration for initial events. This approach is less magic than using a specific constructor by reflection, but in my opinion it makes rebuilding logic and rebuilders registration more complicated and requires a full review of existing code; so I choose an approach that minimizes changes in existing code.I would be happy to have your opinion about this (imho very interesting) topic.