什么时候应该在ASP.NET MVC中创建一个新的控制器类？

Question

我正在学习MVC，并且在决定何时创建新控制器而不是添加与现有控制器相关的操作和视图方面遇到困难。一方面，单一责任似乎是说控制者应该仅限于一些行为。然而，当我尝试这个时，类的数量呈指数级增长（每个类的模型，视图和控制器） - 我想知道我是否会过度。

例如，默认的AccountController具有Login，ChangePassword和Register操作。我倾向于创建一个LoginController，PasswordController和ProfileController以及相关的模型类。所以有1班的时候，会有3-6人。

这有什么好的经验法则吗？

Answer 1

我认为你需要务实。我正在开发一个由StatsController组成的项目。行动的数量在不断增长（RandomStat，MostPopular，MostViewed，MostVoted等等）。这些操作很容易满足，因为StatsController的依赖关系不会改变。我正在使用IoC来满足我的控制器需要的功能，当我开始看到我的控制器需要引用新对象时，这是一个需要分解的信号。

如果您的LoginController，PasswordController和ProfileController都依赖于相同的对象，为什么要将它们分开？

Answer 2

您应该为每个正在操作的模型类型分配一个控制器。控制器充当对这些模型采取行动的一系列行动。这通常是经验法则，但有时控制器的范围超出了单个模型。

AccountController处理与身份验证相关的所有事情。这是超越单一模型范围以涵盖一般身份验证的一个例子。认证的关键部分是什么？检索用户，更改密码等。

Answer 3

我目前的AccountController有12个方法对我来说是完全可管理的。

我有另一个控制器，目前有34个方法，但都是绑定到一个单一的视图，他们每个都有大约8-10行代码最大（检查所需的参数，更新模型，并根据需要重定向）。

他们的关键是将您的业务逻辑封装在一个完全独立的模块中。这将允许您的操作处理程序保持非常轻的重量，并且可以使您的业务逻辑更容易测试。