Question

我尝试按照最佳实践方法构建我最后一个相当大的MVC项目，但我并不完全理解我在做什么。

它有一个数据，业务和Web（MVC）项目，但控制器包含大部分代码，数据层使用NHibernate并且有一些存储库负责太多事情，而Business层是一个倾销场任何不属于其他两个项目的东西。它有效，但我觉得它可以设置得更好 - 我不满意的主要内容是胖控制器和存储库。

我开始一个可能会变得合适的新项目，所以我花了更多的时间试图让我的设计在前面。阅读了一下之后，我尝试为每个聚合根创建一个存储库，然后在表示层中为每个控制器在业务层中提供服务。

我最初的希望是大部分代码都会进入服务中，而这与较小的存储库相结合会使我的控制器和数据层变薄。到目前为止，这还没有发生。

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

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

我错了吗？我是否应该停止尝试盲目跟随我在互联网上阅读的内容，只需在业务层中准备视图模型，这样我就可以将大部分代码移到那里？我应该回到经典的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

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

1 个答案: