管理业务服务层fat控制器的一些Asp.NET MVC2最佳实践

Question

我的控制器越来越大，失控了。

典型的控制器执行以下操作：

• 它确定给定用户是否有访问给定资源的权限。
• 它验证了ViewModel。
• 为了持久化，它将ViewModel转换为DTOModel。
• 它调用存储库来更新/创建新对象以及相关的其他新对象。
• 它访问多个存储库助手类中的数据。
• 它检查用户是否收到通知。
• 它打电话给助手发送电子邮件
• 它通过其他存储库对象将数据记录到数据库。
• 等等。

简而言之，他们策划了很多事情。我想把所有东西都移到一个服务层中，但是在我喜欢的代码示例中还没有真正看到任何已实现的模式。我看过一些开源项目，如KiGG、Oxite、codecampserver、etc...but，它们都没有真正解决我的控制器收缩的问题。我想避免传递很多HTTPContext的东西，但也许这是不可能的。

还有其他的项目，我可以看看的最佳实践吗？我正在构建一个大型的工作流/数据输入应用程序。

谢谢你的一些链接和建议

Answer 1

您应该查看一下关于MVCConf的这个伟大的把你的控制器放在节食上会话。

Answer 2

在我看来，你似乎是依靠你的控制器来扮演太多的角色。

在设计控制器时，我通常认为它是控制对单一类型资源的访问。这意味着，例如，如果我正在创建这个页面，您现在正在阅读，在这里您可以发布答案和评论，我将有2个控制器，一个用于答案，另一个用于评论。对于不相关的资源访问，我将避免向问题控制器添加两个操作。这方面也有例外，但它们很少。

另外，每个控制器的基本功能是，它应该验证输入(即使是在浏览器中验证输入，因为任何人都可以编辑请求)，将输入转换为传递到服务层(或业务逻辑)所需的对象，并在将其转换回视图可用的对象并向用户提供服务之前验证服务层的响应。其他的一切都应该在服务层中处理，保持控制器的细细和可预测。

Answer 3

在我公司，我们总共有5个项目：

• 视图
• 控制器，在这里，我们只将操作方法的逻辑，而它是帮助
• 业务逻辑，在您的情况下，这将是电子邮件、业务验证的助手，我们将调用存储库来更新和创建对象。
• 数据访问，在这里我们放置查询和数据操作的存储库。
• ORM，我们将数据库模型和类放在其中，以便在每个层之间交换数据

在这种情况下，所有项目都有对ORM的引用，然后视图对控制器、控制器对业务逻辑和业务逻辑对数据访问的引用。