设计——依赖地狱解决方案？
我们使用 MVC 架构，其模型由 BLL 和 DAL 组成。
因此，我们为我们的系统开发“模块”，而我正在实现的特定模块使用了大量相同的依赖项。特别是一个类有 20 个依赖项。目前，默认构造函数正在创建一个默认的具体实现，并且我们还有第二个构造函数（第一个构造函数使用的），它允许注入自己的依赖项（即测试）。20
个构造函数参数似乎是一种非常令人讨厌的代码味道。 另一个烦人的事情是，通常当我开始添加通用功能时，我需要在每个类中添加构造函数代码和字段，经常一遍又一遍地重复相同类型的代码。
IoC 容器似乎是一个自然的解决方案，但问题是我能走多远？我是否包含 DAL 依赖项和 BLL 依赖项？ “帮助程序”或“服务”依赖项怎么样？似乎在某个时刻，我只是重新创建“命名空间”结构，能够像静态类一样引用我的类，此时我质疑我实际上获得了什么。
我很难思考这个问题。有人有优雅的解决方案或建议吗？
We use an MVC architecture with a model consisting of a BLL and DAL.
So we develop "modules" for our system and the particular one I am implementing makes use of alot of the same dependencies. One class in particular has 20 dependencies. Currently the default constructor is creating a default concrete implementation, and we also have a second constructor [that the first one uses] that allows one to inject there own dependencies (i.e. testing.)
20 constructor arguments seems like a pretty nasty code smell.
The other annoying thing is that often when I starting to add common functionality, I need to go add constructor code and fields in every class often repeating the same kinds of code over and over again.
An IoC container seems like a natural solution to this, but the problem is how far do I go? Do I include the DAL dependencies and the BLL dependencies? What about "helper" or "service" dependencies? It seems like at a certain point I am just recreating the "namespace" structure with the ability to reference my classes like static classes at which point I question what I am actually gaining.
I am having trouble thinking through this. Does anyone have an elegant solution or advice?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
如果您采用 IoC 路线（我推荐），我会将所有依赖项包含在容器中。
这样做的好处是，您永远不必担心创建这些依赖项，即使它们有很多层深。
例如，ClassA 在其构造函数中接收 4 个其他类，每个类在其构造函数中接收另外两个类，并且每个类至少接收一个 DAL 引用。
在这种情况下，您只需要引用最高层（“组合根”）（可能是您的 UI）中的 IoC ，并说“给我一个对象 A 的实例”，然后IoC 将自动实例化其他 20 个实例，以获取构建对象图所需的各种依赖项。
您的类不再需要担心如何创建它们的依赖项，如果它们需要某些东西，只需将其放入构造函数中，IoC 将确保它得到它。
我还要评论说，即使您使用 IoC，一个类中的 20 个依赖项也是一种明显的代码味道。它通常表明该类做了太多的事情并且违反了单一职责原则。
If you go the IoC route (which I recommend) I would include all your dependencies in the container.
The benefit is that you never have to worry about creating those dependencies, even if there are a ton of them many layers deep.
e.g ClassA takes in 4 other classes in it's constructor, each of those takes in two others in theirs, and each of those takes in at least a DAL reference.
In that case you just need to reference the IoC in your highest-level layer (the "composition root"), which could be your UI, and say "give me an instance of object A", then the IoC will automagically instantiate the other 20 instances for the various dependencies needed to construct the object graph.
Your classes no longer need to worry about how to create their dependencies, if they need something they just stick it in the constructor and the IoC will ensure it gets it.
I would also comment that 20 dependencies in one class is a definite code smell even if you're using IoC. It usually indicates that class is doing far too much stuff and violates the Single Responsibility Principle.