控制器在MVC中的传统使用是否会导致违反单一责任原则？

Question

维基百科描述了 单一责任原则 这边走：

单一责任原则指出，每个对象都应承担单一的责任，责任应完全由班级封装。它的所有服务都应与该责任保持一致。

控制器在MVC中的传统使用似乎使程序员违反了这一原则。采用一个简单的留言簿控制器并查看。控制器可能有两种方法/操作：1）索引（）和2）提交（）。 index（）显示表单。提交（）处理它。这两种方法是否代表了两种不同的责任？如果是这样，单一责任如何发挥？

Answer 1

是的，它确实。

而且，如果您想遵循SRP，则将控制器分解为调度程序和操作；调度器将控制权分配给其动作，并在编译时（C ++模板）或运行时（Java XML，无论如何），您将组成调度程序和动作。

我们为什么不经常看到？由于控制器通常是“临时”的实现，因此没有概括且不愿意将叶子级的混凝土类别进行。在这里，该类更多地用于方便组代码，这些操作几乎可以肯定是非公开的（可能是私人的，可能是受保护的），仅仅是“仅”内部实施细节。

选择如何决定要派遣的行动，可能的行动的数量和多样性是很高的，并且派遣和行动紧密耦合。因此，实际上，将代码放在一个地方通常更容易。

Answer 2

不，不是。

MVC模式或其变化没有任何固有的侵犯单一责任原则的固有。控制器的实施是否违反SRP是基于封装行为是否有多个改变（就像其他类别一样）的理由，而不是因为对模式的任何预设规定使用。

您设置的示例是基本表单上的一个子集，而不是数据应用程序，其中控制器仅为给定模型提供CRUD操作。 CRUD操作本质上具有相当凝聚力，因此这通常不构成违反SRP的行为。在单个控制器上有多种方法开始成为可疑的情况，这些方法代表整个域之间的不同行为相互作用。

也就是说，即使有人认为Crud代表了四个单独的非粘性问题，MVC模式也没有任何固有的迫使您促进同一控制器内的这些动作。

有关MVC模式的一些历史记录以及有关其在Web开发中的应用的讨论，请结帐 交互式应用架构模式.