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:
- Entity types (
A
,B
) - Entity factories (
FactoryA
,FactoryB
) - Entity manager (
Manager
) - 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:
- examine it and find there the relevant assembly level attribute in开发者_Python百科stance
- Create a new
FactoryC
instance using reflection - Invoke
Manager.RegisterFactory
, passing theFactoryC
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.
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.
精彩评论