Architecture 我可以直接在表示层中使用域对象吗

Architecture 我可以直接在表示层中使用域对象吗,architecture,domain-driven-design,Architecture,Domain Driven Design,我最初有以下设置: 表示层使用-->通过WCF生成的服务代理-->实际服务程序集(其中代理从中生成;通过IIS托管)-->域层(业务逻辑)-->DAL 最初就是这样,但发现服务和DAL也应该访问域层。现在我有一个场景,在表示层中,我有一个计算等级的数据网格,我认为应该在域对象中有规则和计算 我的问题是: 表示层是否也应该引用域对象?这是惯例吗 如果是,如果我可以直接访问域对象,为什么我需要服务层?还是我用传统的n层思考?如果没有,我该怎么做 非常感谢您的反馈 更新/编辑: @约罗:谢谢你的回复。

我最初有以下设置:

表示层使用-->通过WCF生成的服务代理-->实际服务程序集(其中代理从中生成;通过IIS托管)-->域层(业务逻辑)-->DAL

最初就是这样,但发现服务和DAL也应该访问域层。现在我有一个场景,在表示层中,我有一个计算等级的数据网格,我认为应该在域对象中有规则和计算

我的问题是:

  • 表示层是否也应该引用域对象?这是惯例吗

  • 如果是,如果我可以直接访问域对象,为什么我需要服务层?还是我用传统的n层思考?如果没有,我该怎么做

  • 非常感谢您的反馈

    更新/编辑:

    @约罗:谢谢你的回复。在你的选项1中,这是我的问题。我无法将要计算的值发送到服务器。我需要让它立即反映在UI中

    例如,我有一个域对象:

    public class Grade
    {
        List<CriterionGrade> children = new List<CriterionGrade>();
    
        public decimal FinalGrade
        { 
            get
            {
                decimal final = 0;
                foreach (CriterionGrade grade in CriterionGrades)
                    total += line.LineTotal;
    
                return total;
            }
        }
    
        public IEnumerable<CriterionGrade> CriterionGrades
        {
            get { return children; } 
        }
    
        public void AddCriterionGrade(CriterionGrade grade)
        {
            children.Add(grade);
        }
    }
    
    公共课等级
    {
    列表子项=新列表();
    公共财政贸易
    { 
    得到
    {
    小数点=0;
    foreach(标准等级中的标准等级)
    合计+=行。行合计;
    返回总数;
    }
    }
    公共数字标准等级
    {
    获取{返回子项;}
    }
    公共空间附加标准等级(标准等级)
    {
    添加(年级);
    }
    }
    
    我现在正在做的是,我有一个包括孩子在内的DTO,但作为DTO,没有业务逻辑。这个DTO和服务层在另一台机器上,我使用WCF获得了一个引用。现在我的演讲是WPF。因此,我将DTO绑定到我的数据网格

    我想要实现的是,每当用户在DataGrid中更改等级时,都应该强制执行FinalGrade规则(FinalGrade也显示在UI中)。现在,由于生成的代理不包含逻辑/规则,我无法访问该规则。我的要求是,在任何更改后,我需要在UI上计算并显示最终版本

    在不重复逻辑的情况下,如何解决这一问题?我唯一能想到的是引用实际的域对象并将计算放在服务中,因为DataGrid绑定到代理,但我不确定这是正确的还是理想的。

    这取决于具体情况

    您提到的“服务”在DDD中称为“应用程序服务”

    如果表示层在物理上与域层分离,则可能需要添加“服务”层(WCF服务、REST服务等),因为在这种情况下无法引用域模型

    但是,如果您的层仅在逻辑上是分开的,那么可以在表示层中引用域对象(在这种情况下,您可以删除“服务”层)

    “应用程序服务”层只是一个“”。它可以通过向前端应用程序(网站、WPF应用程序等)公开更简单的特定于应用程序的API来隐藏域层的复杂性。所以事实上,拥有它没有对错之分。您必须问问自己,您的域层是否如此复杂,以至于您必须添加一个“应用程序服务”层来隐藏复杂性?我宁愿在开始时“保持简单愚蠢”


    顺便说一句:我更喜欢在表示层中使用模式,特别是当您已经在使用像WPF这样的MVVM框架时。在这种情况下,您在视图模型中处理UI逻辑,并将域逻辑委托给域层。

    引用演示文稿中的其他层

    演示可以参考其他层,这是一种常见的做法,因为一些分层体系结构实现了IoC和DI,但这是另一个主题

    即使演示文稿引用了其他层,也不意味着演示文稿可以直接访问域层。您仍然必须考虑是否提交一个干净的逻辑分离(或松散耦合的多层体系结构)。表示层仍然与服务层通信,无论它们是否分离

    如果可以直接访问域,为什么要使用服务层?

    在DDD中,您只为域创建一个单独的层,对吗?正确地封装和抽象该域层(使用服务),使其与应用程序的其余部分(表示)松散耦合,这种松散耦合设计的目的是域中的任何更改都不会影响整个应用程序这是DDD的主要卖点。

    如果您到处引用域,那么域中的更改要求您更改应用程序的其余部分,如ripple effect。但是如果层被适当地分开,那么每一层都可以相互独立地演化,这对于基于团队的开发来说是完美的

    如果您的演示文稿在物理上与域(nTier体系结构)分离,并且仍然希望遵守DDD,我有两个建议:

    选项1

    您可以创建一个“瘦客户机”。它被称为“瘦”,因为它不做任何计算或任何艰苦的工作,服务器为它们做这些。如果客户机想要计算一些东西,它只需将参数发送到服务器(通过Web API或WCF),然后接收计算结果以供显示

    选项2

    如果参数太大(整个数据网格)。您可以在演示文稿中包括服务层。但在逻辑上,表示和服务仍然是分开的

    编辑1: 实际上,您可以以JSON格式发送整个datagrid,并作为响应接收最终等级。如果你是conc