MVC业务逻辑组织

Question

我正在尝试用ASP.Net学习MVC并正在阅读Steve Sanderson的书.我很困惑的一件事是在哪里放置业务逻辑？

例如,删除产品时,所有Sanderson都有一个在CartController中调用productsRepository上的Delete方法的方法.这对我来说很奇怪,因为如果有任何业务逻辑,例如确保产品不在任何人的购物车中,等等,则必须在产品库或CartController中.

这两者似乎都是放置业务逻辑的坏地方; 产品存储库可以很容易地被另一个替换(从使用数据库转换为使用会话),使用Controller意味着您将业务逻辑放在UI层中.

他不应该使用包含业务逻辑的类并调用存储库的delete方法吗？存储库是业务逻辑类的成员变量'？

Answer 1

我通常以类似于以下的方式构建我的MVC解决方案:

• X.Core
  • 常规扩展方法,日志记录和其他非Web基础结构代码
• X.Domain
  • 域实体和存储库
• X.Domain.Services
  • 用于编排复杂域操作的域服务,例如将产品添加到购物车
• X.Application.Core
  • 应用程序逻辑(初始化(路由注册,IoC配置等),特定于Web的扩展,MVC过滤器,控制器基类,视图引擎等)
• X.Application.Models
  • 查看模型类
• X.Application.Services
  • 可以通过访问存储库或域服务返回ViewModel的服务类,以及更新的另一种方式
• X.Application.Web
  • 控制器,视图和静态资源

其中一些可以组合在一起,但将它们分开可以更容易地找到东西并确保您的图层边界得到尊重.

显示产品购物车的典型控制器操作可能如下所示:

public virtual ActionResult ProductCart()
{
    var applicationService = <obtain or create appropriate service instance>
    var userID = <obtain user ID or similar from session state>
    var viewModel = applicationService.GetProductCartModel( userID );
    return View( "Cart", viewModel );
}

用于将产品添加到购物车的典型控制器操作可能看起来像这样:

public virtual ActionResult AddProductToCart( int productID )
{
    var domainService = <obtain or create appropriate service instance>
    var userID = <obtain user ID or similar from session state>
    var response = domainService.AddProductToCart( userID, productID );
    return Json( new { Success = response.Success, Message = response.Message } );
}

Answer 2

我还阅读了 Sanderson 的书的第一版，它非常棒 - 一种非常简单的方法来学习和开始使用 ASP.NET MVC。不幸的是，您无法直接从他书中的概念跳到编写大型可维护应用程序。最大的障碍之一是弄清楚将业务逻辑和其他位于 UI 和持久存储之间的关注点放在哪里（称为关注点分离或 SOC 的概念）。

如果您有兴趣，请考虑阅读领域驱动设计。我不会说我完全了解它，但它是从 Sanderson 的示例应用程序到成功分离 UI 问题、业务逻辑和存储问题的一个很好的过渡。

我的解决方案有一个单独的服务层。控制器与服务层通信（使用依赖注入 - Ninject）。服务层可以访问我的域对象/业务逻辑和我的存储库（NHibernate - 也与 Ninject 一起启动）。我的视图或控制器中的逻辑很少 - 控制器服务于协调器的目的，并且我努力使控制器操作尽可能精简。

我的领域层（实体、业务逻辑等）没有依赖项。它没有引用我的 Web 项目或我的存储库项目。它通常被称为 POCO 或普通旧 C#/CLR 对象。

编辑：我在您的评论之一中注意到您正在使用 EF。如果不使用称为 Code First 的东西（去年 8 月检查时处于社区技术预览状态），EF 就不支持 POCO。仅供参考。