域模型与服务层中的ASP.NET MVC业务逻辑

Question

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

1 - 领域模型.这些真的是什么？在我的Model文件夹中,我只有一堆与我的数据库对应的类.我先使用EF代码.我认为这些是我的域模型.

2 - 服务层.这个答案暗示了一个服务层,我觉得这很有道理.我决定和这个一起去.然而,Martin Fowler的"贫血领域模型"文章搞砸了我的想法.

我不确定如何为我的域模型添加逻辑.

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

Answer 1

首先,您的Asp.Net MVC项目中的Model文件夹应该用于ViewModels.这些是控制器发送给您的视图的模型.它们应该针对View进行高度优化,仅表示视图所需的属性,而不是其他任何属性.

您正在使用的域模型与商业模型相同,属于您的业务层.Asp.Net MVC项目中的Model文件夹是UI Layer的模型.

第二种方法,即服务(真正的业务)层中的业务逻辑不被认为是错误的.它是数据层和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;}
    }
}

Answer 2

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

保持业务逻辑远离域模型将允许我将我的域模型重用于另一个项目.

您可以考虑控制器和数据访问层/ Repositary层之间的中间层来处理这个问题.我将其称为服务层.

Answer 3

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

ViewModels - 这些是轻量级(通常是poco)类,可以为您网站上的页面所需的数据建模.这些类处理向用户显示的内容的平凡样板,并在您要显示的数据发生更改时进行更改.

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

PersistenceModels - 这些是持久性机制的模型.对于我们大多数人来说,这意味着建模数据库表,但也可能是从api请求返回的复杂的nosql文档或json(或其他)数据.他们的责任是处理您的外部数据采用何种形状的普通锅炉板.

请记住,您并不总是需要在项目中提供所有这三种类型的模型.有时你的视图模型将是你的持久性模型的行.在这种情况下,你会浪费你的客户钱来写两遍整个东西并添加一个域模型来映射一个到另一个.你是开发商,你的工作就是知道什么时候建造一个航空母舰去商店购买杂货.