C#C
C#•2y ago
deprecatio

✅ Reengineering repository layer

I'm trying to bring a code base that was left to me to a more modern architecture.
I'm at the point where I need to deal with the repositories because they are becoming a problem.
Creating new classes for manipulating data and re-reouting the flow of the code in the current architecture shouldn't be that much of a problem, but I have some difficulties in understading how to organize code for some common operations.

What I mean is: currently models have some common logic, let's take auditing for example. When a model is created or updated I need to set who did it and when. Stuff like:
[Serializable]
public abstract class AuditedEntity : OtherAuditing
{
    /// <inheritdoc />
    public virtual DateTime? LastModificationTime { get; set; }

    /// <inheritdoc />
    public virtual Guid? LastModifierId { get; set; }
}
public class SomeModel : AuditedEntity { }
public class OtherModel : AuditedEntity { }

I would set these fields once per operation (or say unit of work), seems the reasonable thing to do, but what would be a way to do it?
The only thing I could think of is having a class with specifically an isolated method for this that I call manually every time I touch a model that is audited.
Maybe I could get all the tracked models in the current context from ef and if any inherits from AuditedEntity I update its fields, but that's a little ugly. The other stuff I could come up with would be even uglier.
Am I looking at this the wrong way? The solutions I found searching around are either too old or for bigger projects (this is in the 100_000s of lines) and it would be probably too much to maintain,
Was this page helpful?