如何将 SRP 应用于用户界面类？

【问题标题】：How to apply SRP to user interface classes?如何将 SRP 应用于用户界面类？
【发布时间】：2011-01-18 14:56:06
【问题描述】：

我的应用程序使用 DI 框架，并在必要时遵循“程序到接口”实践。

我使用构造函数注入，因为我想明确地查看依赖关系。但是现在我的表单类的构造函数接受了太多的参数（>=4 例如）。

问题：由于 UI 设计通常不遵循 SRP，因此 Winform 类可能具有 n 构造函数依赖项。你喜欢让它们保持原样，而是传递一个代理对象，使用服务定位器......？考虑到没有使用 aop 框架，您是否还在每个构造函数中注入“方面”（记录器等）？

【问题讨论】：

【解决方案1】：

UI 实现没有理由不遵守 SRP。使用 MVP、MVC 或 MVVM 等模式，UI 类的单一职责是通过 UI 呈现和收集数据。这通常最好通过相当被动的数据结构（例如视图模型）来完成。

构造函数过度注入的问题应该由refactoring to Aggregate Services解决。

【讨论】：

谢谢！两篇文章都很棒。不过，我想稍微打开“UI 设计中的 SRP”部分。您如何应对客户的非标准 UI 要求？例如，涉及多个职责的表单（根据您手头的设计）......我认为可以使用复合视图，每个视图本身都使用 SRP，或者可能重新考虑职责的粒度（如在聚合服务中）。你会走哪条路？
复合视图听起来很合理。每个解决一个较大问题集的一小部分。这基本上是现在或多或少已失效的复合应用程序块所采用的路径。