MVC架构控制器上的大动作方法答案

【问题标题】：MVC architecture large action method on controllerMVC架构控制器上的大动作方法
【发布时间】：2014-02-13 15:27:10
【问题描述】：

我目前正在开发 Controller 的 ActionResult 函数中的业务逻辑，我注意到它变得笨拙...很大...涉及很多页面上下移动。

代码包括填充分配给 ViewBag 属性的下拉列表的列表，但大部分大小都占用了 EF（linq 到实体）并在内存处理中。最后通过 Auto Mapper 发送到视图模型。

移动此代码的最佳位置在哪里？在 Controllers 文件夹中的另一个类中？还是在另一个文件夹中的另一个类中，即业务层？

【问题讨论】：

据我了解，您没有数据访问层。如果有，您可以将所有数据处理代码移至该层，从而减轻您的控制器的负担。
我有模型和视图模型，并且一直认为这意味着我有一个数据访问层 (DAL)。但是，如果 DAL 旨在包含业务逻辑，那么您是对的，我没有 DAL。如果是这样，您/任何人可以向我指出 DAL 最佳实践吗？谢谢。
如果您有 DAL，那么我认为移动代码“包括填充分配给 ViewBag 属性的下拉列表的列表，但大部分大小都占用了 EF（linq to实体）”到那里。
这里所有的好答案！！！每个帖子都回答了我的问题。很难决定。

【解决方案1】：

将您的项目分离到：

业务层WebUI项目调用方法的控制器。如果业务需要从数据库中获取数据，就会调用数据访问层。

【讨论】：

【解决方案2】：

有趣的是，我回答了一个非常相似的问题yesterday. 简而言之，将控制器限制为将模型与视图链接起来的最低逻辑。业务逻辑、数据访问等最好放在单独的存储库中。

【讨论】：

【解决方案3】：

Bappi Datta 是对的。让我从我的角度解释一下。

我对 libs AutoMapper, EF 的最佳实践是：

【讨论】：

【解决方案4】：

您需要拥有存储库层（您提到您已经拥有），然后您需要拥有一个服务层，它可能使用命令工厂和外观等模式来保存所有必要的业务逻辑。那么为了让你拥有一个灵活且易于插拔的架构，你需要使用Dependency Injection between all layers。

在整体 MVC 架构本身的理论讨论中可能存在不同的 If 和 But。但通常您的控制器操作需要精简，您的业务逻辑需要位于存储库之外的不同层中。

【讨论】：