How to use Unity in order to implement a simple component publishing engine.

Question

Dear ladies and sirs.

In our project we have implemented a simple facility to let one party publish dynamic components and yet others - to consume them. I would like to phase out our in-house implementation and take something ready off the shelf. Since our UI guys already use Caliburn+Prism+Unity, I decided to go with Unity (having two different IoC container implementations seems like a strange thing to do).

For the sake of the question, here are the players:

1. Entity types (A, B)
2. Entity factories (FactoryA, FactoryB)
3. Entity manager (Manager)
4. Client

As of now, Manager has RegisterFactory(IFactory) API, which is the only way to register new entity types - one has to call it passing the new entity factory instance.

However, explicit calls to this method by Client are rare, because the Manager runs our in-house engine, which examines all the assemblies in a certain folder and loads those, which declare certain assembly level attribute. The attribute specifies the type of particular entity factory, so that the engine can instantiate it (using Activator.CreateInstance) and invoke the RegisterFactory API.

In addition, the engine monitors the folder and knows to load new assemblies on the fly.

For instance, if C is a new entity type implemented in an assembly Foo.dll, then the assembly should have an assebly level attribute like so:

[assembly: PublishEntity(typeof(FactoryC))]

Then placing Foo.dll in that special folder causes the engine to:

1. examine it and find there the relevant assembly level attribute instance
2. Create a new FactoryC instance using reflection
3. Invoke Manager.RegisterFactory, passing the FactoryC instance as the argument.

The point is that I wish to use Unity to achieve the same functionality.

Any ideas?

Thanks.

EDIT

Both Manager and Factory types are needed. What I am interested to eliminate is the ad-hoc registration facility - the attribute, the RegisterFactory method and the engine that scans the folder and loads the relevant assemblies. Now I realize that Unity may not be enough. I am interested to know about the complimentary solutions which will satisfy our needs. I just wish to use something well known and tested, preferably something aspiring to be standard.

Answer 1

Unity requires a type config, either in the app config or built at runtime. Your current engine adds value by doing assembly probing. Unity just doesn't do that.

The only purpose I see Unity serving is replacing your Manager and possibly your Factory classes by allowing Client to resolve Entities (and Factories?) using Unity. You could keep allowing your engine to hot-configure Unity with assemblies that it finds.