Because when you have 30 entities, several relations, several related lists, you want to ensure by the infrastructure that these fields are managed correctly.
Its not smart save audit for each implementation differently…
Do you have any plan to make security context accesible in the entire app?
Your App is exactly who should be populating your Audit fields since only you’ll know which fields you want populated with what info. Not sure why you’d each populate them differently, have them all call a common method as done in my example above.
There can never be a non static filter, you’re calling a library API which isn’t physically able to access any external dependencies unknown to it like your App or web frameworks it’s called from, it also can’t access object instances it wasn’t called with (you’re requesting to do both), so if you’re not passing in a request context then how can it be possible for an ORM to be able to provide a filter that’s able to access it other than anything apart from a static context? Like how exactly is it supposed to be able to access a non static instance it wasn’t called with to be able to inject it in a filter?
var car = new CarEntity{CustomerId = 1}; Db.Save(car);
I need to handle that in each and every case, there are a lot more cases. I think this shouldb be handled from one place. line in hibernate for example
And how exactly can NHinernate get its security context in .NET Core which disables static access to its request context by default? Given it’s not possible, it has to enable it, so if that’s what you want to do then you’ll need to register the HttpContextAccessor, i.e:
public void ConfigureServices(IServiceCollection services)
{
services.AddHttpContextAccessor();
}
Then you can access an IRequest Context from HttpContext.TryGetCurrentRequest() in your static filters invoked from a HTTP Worker thread, i.e. it’s not possible from a background thread.