Is it possible to use Audit.Net without managing Audit_{Entity}s separately?

Question

Config:

.Net 5
Audit.Net
with Audit.EntityFramework.Identity.Core
EntityFramework DataProvider

Audit.Core.Configuration.Setup()
    .UseEntityFramework(x => x
        .AuditTypeNameMapper(typeName => "Audit_" + typeName)
        .AuditEntityAction<IAuditableEntity>((ev, entry, auditEntity) =>
        {
            auditEntity.AuditDate = DateTime.UtcNow;
            auditEntity.AuditUserName = ev.Environment.UserName;
            auditEntity.AuditAction = entry.Action;
        }));

The most desired behaviour would be the following:

You create a new {Entity} and you add it to the DbContext model
Add-Migration creates the table for the {Entity} and it would automatically create an Audit_{Entity} table as well, that would contain properties of the {Entity} + the properties of the IAuditableEntity interface

But as thepirat000 commented to the question: Dynamic audit table creation via Migrations

The library does not provide any custom migration.

So if I am not mistaken this means you need to create the Audit_{Entity} for every {Entity} to

let Audit.Net know how to map {Entity} -> Audit_{Entity}
let EF know what tables to create

like thepirat000's following example with User and Audit_User classes: https://stackoverflow.com/a/51941354/11213440

Adding properties of the IAuditableEntity interface to the Audit_{Entity} is fine, and can be easily maintained, refactored later on. But what about the properties of the {Entity}?

It is a very possible situation that with future developments we add a new important property to the {Entity} and we (as we are humans) forget to make the exact changes on the Audit_{Entity}. This could lead to a situation where the fact of the forgotten update on the Audit_{Entity} turns out like weeks or months later, and logs created in that period of time would lack this new property.

So my idea was for the Audit_{Entity} is to be inherited from the {Entity} besides implementing the IAuditableEntity interface, to prevent the situation presented a few lines before.

But this results in the following problem:

Choosing inheritation from the {Entity} means I can make decision between Table-per-Hierarchy or Table-per-Type (as Table-per-Concrete Type is not supported in EF Core 5 yet). Both results in storing the Audit_{Entity} entries in the same table, which I would not like to do since searching in a table with 500,000 rows could be really painful.

So the question:

How could I maintain Audit_{Entity}s without editing them separately every time I make changes on the model?

Is it possible to use Audit.Net without managing Audit_{Entity}s separately?

0 Answers0