我最终在模型类的构造函数中有大约 20 个不同的参数,每个服务一个?这是正常现象还是有问题的迹象。
4 回答
我认为,明确地说,您的控制器正在与太多服务进行交互。我还没有看到你的代码——所以我放弃了假设——但在我看来,你的控制器正在通过调用大量“小”服务来组成业务逻辑,而不是利用更少、“更大”的服务来组成业务逻辑从较小的服务。
查看有关“编排服务”与“实体”或“能力”服务的信息,您就会明白我的意思。如果您创建为控制器提供所需逻辑的编排服务,那么您的架构就会得到改进,因为您的控制器实际上根本不应该包含任何业务逻辑。
我真的认为您使用的服务数量是这里的问题。IoC 容器可能会以某种方式解决如何将类型绑定到注入参数等,但我认为问题在于此时的架构。
您可以尝试整合一些服务或考虑将控制器视图部分重构为更小的范围组件。此外,像 Spring 这样的依赖注入风格的框架可以帮助解决这样的事情。
虽然我不知道你的设置。20 似乎有点多,我认为您违反了 SRP(单一责任原则)。但是由于我看不到您的代码,因此无法分辨。如果您确实需要该模型类中的所有这些服务,那么也许您需要将它们放在工厂类中并将其用作参数。
由于我们不知道您的域,因此很难就此给出任何好的答案。
正如@Matt 所说,依赖注入可以帮助你,sprint.NET 是一个很好的,还有其他几个。
当你特别提到 MVP 时,你至少应该看看现在有Unity的Ent Lib 4.1,微软对 DI 的看法。如果这是新的,他们的codeplex站点可能是一个不错的起点。
还有一些与 Visual Studio 集成的软件工厂,并为您提供了为网站创建 MVP 作为链接或 Web 服务的工具。这些也来自模式和实践。