我们有一些功能遵循非常相似的模式：
例如，我们的注册/注册功能遵循此模式。用户提交电子邮件地址，接收电子邮件，然后使用密码创建密码＆amp;用户帐号。另一个例子是密码重置。用户提交电子邮件地址，接收电子邮件，然后使用密码更改密码和访问用户帐户。
模式＃1
我们可以有1个控制器来单独管理每个功能。因此，例如，SignUpController处理所有相关操作（发送电子邮件，兑换代码和创建密码）。然后我们可以使用PasswordResetController来处理发送电子邮件，兑换代码和更改密码。
模式＃2
另一种方法是将操作拆分为控制器。在这种模式中，我们将有一个SendEmailController，它将为这两个功能发送电子邮件，CodeRedemptionController将处理这两个功能的代码更新，以及一个PasswordController，它将处理这两个功能的密码操作。
哪种方法更好？为什么？我们的主要目标是实现高代码简单性，清晰度/可发现性和干燥性。我可以看到这两种模式的优缺点。
模式＃1优势
与该功能相关的所有代码都保存在一个位置。使用TempData字典将数据从一个操作传递到另一个操作更容易理解，并且该功能的流程由单个控制器描述。
模式＃1缺点
依赖注入。每个功能控制器都需要为电子邮件发件人，客户经理（MembershipProvider接口包装器）以及各种存储库注入依赖项。使用构造函数注入时，构造函数会有很多参数。
模式＃2的优点和缺点恰恰相反。我们可以简化控制器的依赖关系，但这些功能将分布在多个控制器上，模糊了整个应用程序试图实现的功能的清晰度。
答案 0 :(得分：0)
我会使用单个帐户控制器来管理所有相关的用户管理功能。该控制器将是用户处理这些类型功能的接入点。
然后，我会将您提到的单独逻辑分离到不同的模型类中，这些模型类将根据需要由该控制器调用。例子：
/models/EmailManager.cs
/models/PasswordManager.cs
/models/SecretCodeGenerator.cs
/models/AccountManager.cs
这将允许您拥有整合的url语法。它可以让你避免使用只有一种方法的许多控制器。它可以防止你在控制器中拥有大量的模型类型逻辑。
www.mydomain.com/account/signup/
www.mydomain.com/account/confirm/
www.mydomain.com/account/resetpassword/
（使用自定义路线，如果愿意，您甚至可以删除/ account / part）
但是，我可能想要创建一个自定义控制器来处理密码的兑换。 （redeemController）通过这种方式，您可以控制对授权/现有用户的大部分accountController的访问权限，而兑换控制器（取决于您的设计）可能对新客户开放匿名。
最后，拥有模型类中的大部分逻辑使它们更加适合测试。