如何使用Unity来实现一个简单的组件发布引擎
在我们的项目中，我们实现了一个简单的工具，让一方发布动态组件，而另一方则可以使用它们。我想逐步停止我们的内部实施并采取现成的措施。由于我们的 UI 人员已经使用了 Caliburn+Prism+Unity，所以我决定使用 Unity（拥有两个不同的 IoC 容器实现似乎是一件奇怪的事情）。
为了解决这个问题，以下是参与者：
- 实体类型 (
A,B) - 实体工厂 (
FactoryA,FactoryB< /code>) - 实体管理器 (
Manager) - 客户端
目前，Manager 拥有 RegisterFactory(IFactory) API，这是唯一的注册方式新的实体类型 - 必须通过新的实体工厂实例来调用它。
然而，客户端显式调用此方法的情况很少见，因为 Manager 运行我们的内部引擎，该引擎会检查特定文件夹中的所有程序集并加载那些声明特定程序集级别属性的程序集。该属性指定特定实体工厂的类型，以便引擎可以实例化它（使用Activator.CreateInstance）并调用RegisterFactory API。
此外，引擎会监视文件夹并知道动态加载新程序集。
例如，如果 C 是在程序集 Foo.dll 中实现的新实体类型，则该程序集应具有如下所示的程序集级属性：
[assembly: PublishEntity(typeof(FactoryC))]
然后将 Foo.dll 放入该特殊文件夹中会导致引擎：
- 检查它并在那里找到相关的程序集级别属性实例
- 使用反射创建一个新的
FactoryC实例 - 调用
Manager.RegisterFactory，将FactoryC实例作为参数传递。
重点是我希望使用Unity来实现相同的功能。
有什么想法吗？
谢谢。
编辑
Manager 和 Factory 类型都是需要的。我有兴趣消除的是临时注册工具 - 属性、RegisterFactory 方法以及扫描文件夹并加载相关程序集的引擎。现在我意识到 Unity 可能还不够。我有兴趣了解能够满足我们需求的免费解决方案。我只是想使用一些众所周知的和经过测试的东西，最好是那些渴望成为标准的东西。
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 instance
- Create a new
FactoryCinstance using reflection - Invoke
Manager.RegisterFactory, passing theFactoryCinstance 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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
Unity 需要一个类型配置，无论是在应用程序配置中还是在运行时构建。您当前的引擎通过进行装配探测来增加价值。 Unity 只是不这样做。
我认为 Unity 服务的唯一目的是通过允许客户端使用 Unity 解析实体（和工厂？）来替换您的 Manager 和可能的 Factory 类。您可以继续允许引擎使用它找到的程序集热配置 Unity。
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.