37

我一直在阅读有关在 ASP.NET MVC 项目中放置业务逻辑的位置一段时间，但我仍然无法弄清楚某些事情。

1域模型。这些到底是什么？在我的模型文件夹中，我只有一堆与我的数据库相对应的类。我首先使用 EF 代码。我假设这些是我的领域模型。

2-服务层。这个答案暗示了一个服务层，我认为这很有意义。我决定和这个一起去。然而，Martin Fowler 的“贫血域模型”文章让我大吃一惊。

我不确定如何向我的域模型添加逻辑。

我经历了许多与业务逻辑相关的问题，每个问题都提出了 1 或 2。我不明白如何实现第一个。向实体类（对我来说是域模型）添加方法根本没有意义。为什么第二种方法被认为不好？

4

5 回答 5

27

首先，您的 Asp.Net MVC 项目中的 Model 文件夹应该用于 ViewModel。这些是控制器发送到视图的模型。它们应该针对 View 进行高度优化，这意味着只有 View 所需的属性，没有别的。

您所从事的领域模型与业务模型相同，属于您的业务层。Asp.Net MVC 项目中的 Model 文件夹是 UI 层的模型。

第二种方法，您的服务（真正的业务）层中的业务逻辑并不被认为是坏的。它是您的数据层和 UI 层（3 层架构）之间的一个非常好的缓冲区。您的数据层负责从 Web 服务或数据库获取数据，而您的业务/服务层负责将这些数据转换为业务/域模型。它还包含任何业务逻辑，例如计算等。

这些业务/领域模型通常是 POCO，但并非必须如此。这就是我有时设置商业模式的方式：

public class BusinessObject
{
    private DataObject _dataObject;

    public BusinessObject(DataObject dataObject)
    {
        _dataObject = dataObject;
    }

    public int BusinessId
    {
        get {return _dataObject.Id;}
        set {_dataObject.Id = value;}
    }

    public string Name
    {
        get {return _dataObject.Description;}
        set {_dataObject.Description = value;}
    }
}
于 2013-02-02T01:38:15.180 回答
14

我更喜欢在域模型中没有业务逻辑。我通常将我的域模型作为 POCO 来表示我的数据库表/模式。

使业务逻辑远离域模型将允许我在另一个项目中重用我的域模型。

您可以考虑在控制器和数据访问层/存储层之间设置一个中间层来处理这个问题。我将其称为服务层。

于 2013-02-02T01:29:26.907 回答
10

我知道这已经得到解答，但我将模型分为 3 组

ViewModels - 这些是轻量级（通常是 poco）类，用于对您网站上的页面所需的数据进行建模。这些类处理向用户显示的普通样板文件，并在您要显示的数据更改时更改。

DomainModels - 这些通常是重量级的业务逻辑类。他们通常为您正在做的事情建模核心业务规则。这些类通常具有很强的凝聚力，并且是使您的网站与众不同的大部分工作发生的地方。我说这些模型通常是重量级的，但实际上如果你的项目所做的只是从用户那里获取数据并将其保存在数据库中，那么这个类将是一个小的数据映射类。很多时候，您会看到这些类由持久性模型和返回视图模型组成。

PersistenceModels - 这些是您的持久性机制的模型。对于我们大多数人来说，这意味着对数据库表进行建模，但也可能是从 api 请求返回的复杂 nosql 文档或 json（或其他）数据。他们的职责是处理您的外部数据所采用的普通样板。

还要记住，您并不总是需要在您的项目中包含所有这三种类型的模型。有时，您的视图模型将逐行显示您的持久性模型。在这种情况下，您将浪费您的客户的钱来编写整个内容两次并添加一个域模型以将一个映射到另一个。您是开发人员，您的工作是知道何时建造航空母舰去商店购买杂货。

于 2014-03-25T16:06:16.100 回答
2

领域模型应该能够自己执行它们的工作并公开表示它们的状态和功能的属性和方法。它们充当模型运行所需的信息层次结构的根（聚合根）。它们保持隐藏状态，仅对服务可用。

服务通过从封装数据访问层的存储库中检索模型，然后调用方法/业务，将业务/域功能作为一组遵循消息模式（请求/响应）的 API 向外部世界（Web 服务、UI 等）公开模型上的功能，最后将它们保存回存储库。

有时感觉服务重复业务对象的方法，但在时间和实际实践中，实际情况并非如此。

在真正的领域驱动设计中，您至少需要 3 组对象。业务对象、业务对象和服务的存储库。

假设您的要求始终是每种类型的组件都由不同的团队编写。一个团队需要一个公开的服务而不知道细节，另一个团队不必在自己的服务上编写逻辑。然后，任何需要它的人都可以使用该服务，而无需深入研究核心模型本身。

于 2018-07-24T18:21:15.387 回答
-1

应用程序流控制逻辑属于控制器。

数据访问逻辑属于存储库。

验证逻辑属于服务层。

服务层是 ASP.NET MVC 应用程序中的一个附加层，它调解控制器和存储库层之间的通信。

服务层包含业务验证逻辑。

例如，产品服务层具有 CreateProduct() 方法。

CreateProduct() 方法调用 ValidateProduct() 方法来验证新产品，然后再将产品传递到产品存储库。

来源： http ://www.asp.net/mvc/overview/older-versions-1/models-data/validating-with-a-service-layer-cs

于 2016-07-14T10:09:04.540 回答