Presenter 类的构造函数中有一长串参数是否正常？
警告缩写超载即将来临！！！ 我正在使用 MVP 被动视图模式和 DI 进行 TDD 和 DDD。 当我编写每个新测试时，我发现自己不断地向演示者类的构造函数添加依赖项。 大多数是域对象。 我正在使用工厂进行依赖注入，尽管我最终可能会转向 IoC 容器。
当使用构造函数注入（与属性注入相反）时，很容易看到依赖项在哪里。 大量的依赖关系通常表明一个类有太多的责任，但对于演示者来说，我不知道如何避免这种情况。
我曾想过将所有域对象包装到一个“域”类中，该类将充当中间人，但我有这种直觉，我只会转移问题而不是解决问题。
我错过了什么还是这是不可避免的？
Warning acronym overload approaching!!! I'm doing TDD and DDD with an MVP passive view pattern and DI. I'm finding myself adding dependency after dependency to the constructor of my presenter class as I write each new test. Most are domain objects. I'm using factories for dependency injection though I will likely be moving to an IoC container eventually.
When using constructor injection (as apposed to property injection) its easy to see where your dependencies are. A large number of dependencies is usually an indicator that a class has too much responsibility but in the case of a presenter, I fail to see how to avoid this.
I've thought of wrapping all the domain objects into a single "Domain" class which would act as a middle man but I have this gut feeling that I'd only be moving the problem instead of fixing it.
Am I missing something or is this unavoidable?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
通常，方法（构造函数、函数等）的大量参数会产生代码味道。 很难理解所有的论点是什么。 如果您有大量相同类型的参数，则尤其如此。 他们很容易感到困惑，这可能会引入微妙的错误。
这种重构称为“引入参数对象”。 无论这是否真的是一个域对象，它基本上都是一个数据传输对象，它最大限度地减少了传递给方法的参数数量，并为它们提供了更多的上下文。
Often a large number of arguments to a method (constructor, function, etc) is a code smell. It can be hard to understand what all the arguments are. This is especially the case if you have large numbers of arguments of the same type. It is very easy for them to get confused which can introduce subtle bugs.
The refactoring is called "Introduce Parameter Object". Whether that's really a domain object or not, it is basically a data transfer object that minimizes the number of parameters passed to a method and gives them a bit more context.
如果我需要从一开始就在构造函数中添加某些内容，我只会在构造函数上使用 DI。 否则，我使用属性并对其他项目进行延迟加载。 对于 TDD/DI，只要您可以在需要时注入该项目，就不需要将其添加到构造函数中。
我建议始终遵循 Demeter 定律，而不是遵循“一切都需要在构造函数中”的 DI 神话。 Misko Hevery（Google 敏捷教练）在他的博客上对此进行了很好的描述 http://misko.hevery.com/2008/10/21/dependency-injection-myth-reference-passing/
I only use DI on the Constructor if I need something to be there from the start. Otherwise I use properties and have lazy loading for the other items. For TDD/DI as long as you can inject the item when you need it you don't need to add it to your constructor.
I recommend always following the Law of Demeter and not following the DI myth of everything needs to be in the constructor. Misko Hevery (Agile Coach at Google) describes it well on his blog http://misko.hevery.com/2008/10/21/dependency-injection-myth-reference-passing/
拥有 Layer Supertype 可能不是一个坏主意，但我认为你的代码味道可能表示别的东西。 Geofflane 提到了重构模式，引入参数对象。 虽然这是解决此类问题的一个很好的模式，但我并不完全确定这是解决这种情况的方法。
问题：为什么要将域模型对象传递给构造函数？
存在太多抽象的情况。 如果有一层可靠的代码值得您信任，那就是您的域模型 。 当您处理 Customer、Vendor 和 Product 类时，如果这些是基本域模型的一部分并且您不一定需要多态性，则不需要引用 3 个 IEntity 对象。
我的建议：传递应用程序和域服务。 信任您的领域模型。
编辑：
在夜深人静的时候重新阅读问题，我意识到你的“域类”已经是引入参数对象重构，而不是，事实上，层超类型，正如我所想的那样凌晨3点。
我还意识到，也许您需要在 Presenter 之外的应用程序代码中引用 Model 对象。 也许您正在对模型对象进行一些初始设置，然后再将它们传递给演示器。 如果是这种情况，您的“域类”想法可能是最好的。 如果有一些初始设置，当转移到 IoC 时，您需要查看类似 温莎城堡的工厂支持。 （其他 IoC 容器也有类似的概念。）
Having a Layer Supertype might not be a bad idea, but I think your code smell might be indicating something else. Geofflane mentioned the refactor pattern, Introduce Parameter Object. While it's a good pattern for this sort of problem, I'm not entirely sure it's the way to go for this situation.
Question: Why are you passing in Domain Model objects to the constructor?
There is such a thing as having too much abstraction. If there's one solid layer of code you should be able to trust, it's your Domain Model. You don't need to reference 3 IEntity objects when you're dealing with Customer, Vendor, and Product classes if those are part of your basic Domain Model and you don't necessarily need polymorphism.
My advice: Pass in application and domain services. Trust your Domain Model.
EDIT:
Re-reading the problem when it's not horribly late at night, I realize your "Domain class" is already the Introduce Parameter Object refactoring and not, in fact, a Layer Supertype, as I thought at 3AM.
I also realize that perhaps you need to reference the Model objects in the application code, outside the Presenter. Perhaps you're doing some initial setup of your Model objects before passing them in to the Presenter. If this is the case, your "Domain class" idea might be best. If there is some initial setup, when moving to an IoC, you'll want to look at something like Factory Support in Castle Windsor. (Other IoC containers have similar concepts.)