asp.net-mvc-4 - ASP.NET MVC 解决方案的最佳结构

Question

我尝试按照最佳实践方法构建我的上一个大型 MVC 项目，但不太明白我在做什么。

它有一个数据、业务和Web(MVC)项目，但是 Controller 包含了大部分代码，数据层使用NHibernate并且有一些存储库负责太多的事情，而业务层是一个垃圾场任何不属于其他两个项目的内容。它可以工作，但我觉得它可以设置得更好 - 我不满意的主要是胖 Controller 和存储库。

我正在开始一个新项目，该项目可能会发展到相当大的规模，所以我花了更多的时间来尝试让我的设计预先做好。阅读了更多内容后，我尝试为每个聚合根创建一个存储库，然后在业务层为表示层中的每个 Controller 提供一个服务。

我最初的希望是，大部分代码将进入服务，这与较小的存储库相结合将使我的 Controller 和数据层保持精简。但到目前为止，这还没有发生。

我读到的所有内容都表明 View 模型不应从业务层返回，而应填充在表示层中，因此目前我的服务层主要将模型从数据层传递到表示层然后，该层执行准备 View 模型所需的操作。所以我仍然有胖 Controller ，加上瘦业务和数据层。

我的表示层也了解我的业务层和数据层，但我认为这种分离的部分目的是为了减少耦合？

我这一切都错了吗？我是否应该停止尝试盲目遵循我在互联网上阅读的内容，而只是在业务层中准备 View 模型，以便我可以将大部分代码移到那里？我应该回到经典的 ASP 吗？ :)

Answer 1

我在设置项目结构时使用的主要指南是确保我可以向业务逻辑层添加一些操作契约属性，然后将其托管为 wcf 服务。

如果我能做到这一点，那就意味着业务逻辑层已经隔离了我的数据层，并且仅通过传递简单的结构和实体来与其客户端进行交互。数据层完全隐藏。

所以我通常的结构如下:

Solution
    Business.Contracts (interfaces for bll layer in here)
    Business.Logic     (concrete implementations of contracts in here)
    Business.Entities  (Pocos that bll uses)
    Data.Contracts     (interfaces for dal)
    Data.Sql           (Concrete Sql implementation of contracts)
    Common.Enums       (Enums needed by all projects)
    FrontEnd           (Main mvc app)

所以在这个结构中，我的 mvc 项目只处理业务命名空间和公共(public)命名空间。

然而，在与实体交互时，我倾向于在 mvc 项目中使用自己的模型来添加注释和前端特定功能，然后我为这些模型提供隐式转换，以便能够与商业实体。

HTH