ASP.NET MVC 解决方案的最佳结构

Question

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

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

我正在开始一个新项目，该项目可能会变得相当大，因此我会花更多时间来尝试将我的设计提前。阅读更多内容后，我尝试为每个聚合根创建一个存储库，然后在业务层中为表示层中的每个控制器提供一个服务。

我最初的希望是大部分代码都将放在服务中，再加上较小的存储库，这将使我的控制器和数据层保持精简。但到目前为止，这还没有发生。

我读过的所有内容都表明视图模型不应该从业务层返回，而应该填充在表示层中，所以目前我的服务层主要是将模型从我的数据层传递到表示层然后它会执行准备视图模型所需的工作。所以我仍然有胖控制器，加上瘦业务和数据层。

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

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

Answer 1

我在设置项目结构时使用的主要指南是确保我可以将一些 operationcontract 属性添加到业务逻辑层，然后将其托管为 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 项目只处理业务命名空间和公共命名空间。

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

HTH