-
Notifications
You must be signed in to change notification settings - Fork 18
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
♻️ Entity - fix hierarchy - Entity dependency on AuditableEntity #282
Comments
CC: @christoment @wicksipedia @matt-goldman As per our conversation on Teams, I would like to see an open team discussion and several questions answered before commiting this change. I've got some concerns about adding a full audit tracking system into a CA/DDD template. Especially one that introduces a 2nd DB context and additional DB schema. It's a substantial change to make, and I'm not convinced it should be the default OOTB behaviour for the template.
|
I love options so I'm really keen on having a standard way to do this. Correct me if I'm wrong, but looking from where we implement it, we can either: I think we should check on when we should go with A/B/C first (pros & cons).
|
The PR isn't intended on being merged in its current state - it was more of a spike to see what was possible to get working. Ideally, I'd prefer to see SQL dbs using triggers to snapshot the info. Cosmos would be a change feed implementation, but not sure how that would work right now.
Having just built out this spike, I think it may make more sense to build this as a separate package that can be reused. That way you can wire in via DI and choose between the simple user/timestamp column "auditing", or a more full featured one. This may help reduce the cognitive load on the 2nd context etc (not saying that we stay with this approach). But I strongly believe that knowing what changed is incredibly valuable especially if you can see that over time.
No, but again this was only a spike into what was possible with code alone not a fully worked solution.
I believe that it's better to have really good defaults at the starting point.
Yep agree, but there needs to be more time than 1/2 day to look into the other solutions |
@wicksipedia thanks for the reply. Did you still want to address the original issue relating to |
Closing this for now as we're not adding full on auditing into the CA template. Can create a separate reference architecture if needed. |
Found in #277
The inheritance model looks upside down - This feels backwards that all Entities are Auditable, but not all AuditableEntities are Entities?
Recommendations (either):
Entities can inherit from
Entity<TId>
orAudiableEntity<TId>
(which itself inherits fromEntity<TId>
IAudiableEntity
to use default implementationsThis adds the risk of making the auditable fields
protected
notprivate
It also means that entities will need to implement the interface as required instead of it being hidden away
IAuditableEntity
as a marker interfaceAdd an
EntityAudit
table that records table name, id, modified date, and json stringified entityRefactor interceptor to insert rows when entities are added/modified
As per conversation with @christoment and @matt-goldman - we decided to go with option 3 as it kept the demonstrable value of EF interceptors and added more business value to the "auditing" part.
The text was updated successfully, but these errors were encountered: