最佳实践 - 在 Asp.net MVC 中跨层共享 UnityContainer？
我有一个 UnityContainer，它在运行时在 MVC Web 应用程序的 global.asax 文件中获取其配置信息。
我还在另一个程序集中有需要访问此容器的服务，以便它们可以手动执行解析。
我怎样才能最好地分享这两者？ 我不想在数据程序集和 MVC 之间建立引用，但我希望数据程序集能够访问由 Web 应用程序配置的 UnityContainer。
我想知道其他人在这种情况下正在做什么。
I have a UnityContainer that gets it's configuration information at runtime in the global.asax file of an MVC web app.
I also have services in another assembly that need access to this container so that they can perform resolutions manually.
How can I best share the two? I don't want to have a reference between my Data assembly and MVC, but I want the data assembly to have access to the UnityContainer that was configured by the web app.
I'm wondering what others are doing in this situation.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我只是将容器注册到其自身中，然后让依赖项在引用的层中级联。
ie
// 配置容器
等等
废话
blah
// 注册自身
Container.RegisterInstance(Container);
然后任何需要它的人都可以将其作为依赖属性或构造函数参数。
I just registered the container into itself, and then let the dependencies cascade throughout the referenced tiers.
ie
// configure container
blah
blah
blah
// register itself
Container.RegisterInstance(Container);
Then anyone that needs it just has it as a dependent property or constructor param.
我正在使用 StructureMap （类似工具），并且通常在解决方案中跨项目共享我的配置。 这意味着它们本身并不直接共享相同的对象，除非它们在相同的上下文中工作。 在一个简单的应用程序中，网站加载程序集以执行从控制器到业务层，然后到 dal 的工作......它们确实使用相同的对象。 但是，一旦您需要将层放入物理上独立的层（硬件）中，那么配置就可以随之而来。 这成为当时的部署问题。
I am using StructureMap (similar tool) and generally share my configuration across projects in a solution. This means that they are not directly sharing the same object per-se unless they are working in the same context. In a simple application where the website is loading the assembly to perform work from the controller to the business layer and then into the dal...they are indeed using the same object. But as soon as you need to put your tier's into physically separate layers (hardware) then the config can go with it. This becomes a deployment issue at that time.