我目前正在Controller的ActionResult函数中开发业务逻辑，并且我已经注意到它变得笨拙......大......涉及很多页面起伏。MVC架构在控制器上的大动作方法
代码包括分配给ViewBag属性的下拉列表的填充列表，但大多数大小被占用EF（linq到实体）以及在这个的内存处理中。 最后通过Auto Mapper发送到视图模型。
移动此代码的最佳位置在哪里？在Controllers文件夹中的另一个类中？或者在另一个文件夹中的另一个班级中，即业务层？
分开你投射到：
业务层的WebUI项目调用方法的控制器。 如果业务需要数据库中的数据，那么它将调用数据访问层。
有趣的是，我回答了一个非常类似的问题yesterday.总而言之，限制你的控制器只是将你的模型与你的视图链接起来的最低逻辑。业务逻辑，数据访问等更好地放置在单独的存储库中。
Bappi Datta是对的。让我从我的角度来解释一下。
我最好与库AutoMapper，EF是实践：
您需要拥有存储库层（您提到您已拥有），然后您需要有一个服务层，可能使用Command Factory和Facades等模式来保存所有必需的业务逻辑。然后，为了让您拥有灵活且易于插拔的架构，您需要使用Dependency Injection between all layers。
Read about MVC architecture in my perspective
可以有不同的如果的和，但在整体的MVC架构本身的理论探讨。但是一般来说，你的控制器动作需要精简，你的业务逻辑需要位于存储库以外的其他层。
依赖注入...当服务层完成时，我将不得不查看这个并实现它。谢谢你，我听说过这个，但从来没有看过它。和伟大的网站intstrings！ –
据我所知，你没有数据访问层。如果你有，你可以将所有的数据处理代码移动到该层，从而减轻你的控制器负担。 –
我有模型和视图模型，并一直认为这意味着我有一个数据访问层（DAL）。但是，如果DAL旨在包含业务逻辑，那么您是正确的，我没有DAL。如果是这样，你们能否指出我达到DAL最佳实践？谢谢。 –
如果你有一个DAL，那么我认为把你的代码“包括分配给ViewBag属性的下拉列表填充列表，但大部分大小占用EF（linq到实体）”是一个好主意。 –