IoC容器配置
IoC 容器的配置应该如何组织？我知道通过代码注册应该放在应用程序的最高级别，但是如果应用程序有数百个需要注册的依赖项怎么办？与 XML 配置相同。我知道您可以将 XML 配置拆分为多个文件，但如果有人必须挖掘多个 XML 文件，这似乎会成为维护麻烦。
是否有组织依赖项注册的最佳实践？从我看过的所有视频和教程来看，演示中使用的代码非常简单，可以放置在一个位置。我还没有遇到过使用大量依赖项的示例应用程序。
How should the configuration for an IoC container be organized? I know that registering by code should be placed at the highest level in an application, but what if an application had hundreds of dependencies that need to be registered? Same with XML configurations. I know that you can split up the XML configurations into multiple files, but that would seem like it would become a maintenance hassle if someone had to dig through multiple XML files.
Are there any best practices for organizing the registration of dependencies? From all the videos and tutorials that I've seen, the code used in the demo were simple enough to place in a single location. I have yet to come across a sample application that utilizes a large number of dependencies.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
Autofac 和其他公司（例如 Ninject）为此目的采用了模块概念。 http://code.google.com/p/autofac/wiki/StructuringWithModules可能就是您正在寻找的。
热值
缺口
Autofac and others (eg Ninject) employ a module concept for this exact purpose. http://code.google.com/p/autofac/wiki/StructuringWithModules may be what you're looking for.
Hth
Nick
如果我们知道您是否在谈论任何特定的 IoC 容器，将会有所帮助。
例如，Windsor 允许您跨各种 XML 文件定义依赖关系（按照您想要的方式组织），并简单地包含在配置中。结构的格式应该有意义。拥有控制器、设施等的文件/文件夹。相关项目的层次结构。
使用更面向代码的东西，例如 Autofac，您可以轻松创建大量容器配置提供程序来支持您的配置。使用 Hiro，您根本不需要进行太多配置。
无论使用什么容器，它们都提供基于约定优于配置的注册的设施，因此这应该是清理注册的第一站。一个很好的例子是在 MVC 应用程序中注册名称以“Controller”结尾的所有类。
It would help a little if we knew if you were talking about any particular IoC Container.
Windsor, for example, allows you to define dependencies across a wide range of XML files (organised however you want), and simply included in the configuration. The structure should be in a format that makes sense. Have a file/folder for Controllers, Facilities, etc etc. A heirarchy of related items.
With something more code-oriented, such as Autofac, you could easily create a host of container configuration providers to power your configuration. With Hiro, you don't really need to do much configuration at all.
Regardless of the container used, they all provide facilites for convention-over-configuration based registrations, so that should be your first stop in cleaning up registrations. A great example would be to register all classes whose name ends in 'Controller' in an MVC application.