什么时候应该在ASP.NET MVC中创建一个新的控制器类？
我正在学习MVC，在决定何时应该创建一个新的控制器时遇到了麻烦，而不是仅仅添加一个与现有控制器相关联的操作和视图。一方面，单一的责任似乎表明一个控制器应该被限制为几个动作。然而，当我尝试这样做时，类的数量呈指数级增长(每个类都有模型、视图和控制器)--以至于我想知道我是不是走得太远了。
例如，默认AccountController具有登录、ChangePassword和注册操作。相反，我倾向于创建LoginController、PasswordController和ProfileController以及相关的模型类。所以只要有一个班级，就会有3-6个班级。
这方面有什么好的经验法则吗？
回答 3
Stack Overflow用户
发布于 2009-01-08 05:31:50
我认为你需要对此采取务实的态度。我正在做一个由StatsController组成的项目。动作的数量在持续增长(RandomStat、MostPopular、MostViewed、MostVoted等)清单不胜枚举。这些操作很容易满足，因为StatsController的依赖关系不会改变。我使用IoC来满足我的控制器的需求，当我开始看到我的控制器需要引用新对象时，这是一个信号，表明它们需要被拆分。
如果您的LoginController、PasswordController和ProfileController都依赖于相同的对象，为什么要拆分它们呢？
Stack Overflow用户
发布于 2009-01-07 23:36:21
您应该为您正在操作的每个模型类型指定一个控制器。控制器充当作用于这些模型的操作的集合。这通常是经验法则，但有时控制器的作用域超越了单一模型。
AccountController处理所有与身份验证相关的事情。这是一个超越单一模型范围的示例，通常包含身份验证。身份验证的关键部分是什么？检索用户、更改密码等。
Stack Overflow用户
发布于 2009-01-08 06:03:59
我现在的AccountController有12个方法，这对我来说是完全可管理的。
我还有另一个控制器，它目前有34个方法，但它们都绑定到单个视图，每个都有大约8-10行代码(检查所需的参数，更新模型，并在必要时重定向)。
关键是将您的业务逻辑封装在一个完全独立的模块中。这将允许您的操作处理程序保持非常轻量级，并可以使测试您的业务逻辑变得更容易。
https://stackoverflow.com/questions/422622
复制相似问题
腾讯云开发者
