Since auditing is done via DI, it is hard to know in your production system if it is working or not. Literally have to go change a record and examine the audit table to make sure all configurations are correct and all DI's were done on all necessary classes.

Would be nice to somehow verify or know what happened. Maybe a call in that would return a list of what entities had active DI on them or something so we could easily verify on deployment (and during testing) that everything was working as designed.

Thoughts?

Mmm.. IMHO the beauty of DI is that exactly: you set it on and DI occurs, you set it off and it DI doesn't occur. Of course, the obvious and practical thing to know everything is OK is by verifying the persisted data.

Yes, that would be ideal. However, if you have auditing on 37 tables, each with their own configured auditor, etc - would be nice to somehow build some screen or something where you could see that - just for verification.

The DI layer is all setup with this info, so......

Just an idea!

Wayne, How could you achieve that with a third agnostic tool? IMHO, I see that tricky, as DI occurs as you instantiate objects (entities). I would prefer to write UnitTests to be sure DI is correctly set and working.

I disagree. When the application loads, the DI scans your code and attaches itself to certain classes, etc. It is this attachment I would like to verify. By a simple 'listClassesAttachedTo', or something.

Unit tests - of course, but I generally do not run unit tests in production!

WayneBrantley wrote:

I disagree. When the application loads, the DI scans your code and attaches itself to certain classes, etc. It is this attachment I would like to verify. By a simple 'listClassesAttachedTo', or something.

Unit tests - of course, but I generally do not run unit tests in production!

You mean: a customerentity is instantiated and you want to verify with code if the proper validator/auditor etc. is injected?

You can. Create a partial class of CommonEntityBase. In there you override PerformDependencyInjection() and FIRST call the base class.

After that call, the elements to inject should be there. So then you call a central class which does the verification and gets the entity instance and checks, based on a table or something, if the proper instances are injected.

So the override to PerformDependencyInjection is just 2 method calls: 1 to the base, and one to the verifyer.

Yes, sort of...

When the DI code loads, it uses the settings in the .config files to scan all classes, locate the auditors and locate the classes it will be injecting into, right?

It is that list I want to see....

Ah the DI injection info stuff... That's not publicly available, sorry. It's internal.

(DependencyInjectionInfoProviderSingleton.GetInstance(), returns the provider with the info, but that class is internal)

That is what I was looking for. Would be nice if I could get a list of Classes that it had decided to inject into....Then I could easily verify it was working.

If not, I understand.

WayneBrantley wrote:

That is what I was looking for. Would be nice if I could get a list of Classes that it had decided to inject into....Then I could easily verify it was working.

If not, I understand.

Use reflection?

Cheers Simon

They won't be made public, as that would make it harder for us to migrate code to a different codebase/layout. They are solely used internally, so they aren't public. It's also a store which requires locking to access, hence it's not public.