c# – 域名实体或持久性是否应该生成DTO？

2019-06-23 12:56:11 阅读：156 来源： 互联网

标签：c architecture domain-driven-design

当谈到具有现代ORM的分层应用程序时,我常常不确定如何创建特定类以遵守所谓的“最佳实践”,同时还要关注性能要求.

考虑到应用程序中可能包含以下任意类型的对象：

>域实体 – 这些是包含业务逻辑的丰富类(对吗？),并且根据ORM功能,可能与持久性设计直接相关.
> DTO – 这些是更简单的类,它们剥离业务逻辑,以便将数据传递给内部和外部客户端.有时这些是扁平化的,但并非总是如此.
>视图模型 – 它们与DTO类似,因为它们更简单,没有业务逻辑,但它们通常非常扁平,并且通常包含与它们所服务的UI相关的其他位.

我遇到的挑战是,在某些情况下,域实体或任何面向持久性的类映射到更简单的实体(如DTO或ViewModel)会阻止您进行重要的性能优化.

例如：

假设我有一些域实体看起来像这样：

public class Event
{
    public int Id { get; set; }
    public string Name { get; set; }
    public DateTime EventDate { get; set; }

    // These would be reference types in most ORMs
    // Pretend in the setter I have logic to ensure the headliner =/= the opener
    public Band Headliner { get; set; }
    public Band Opener { get; set; }
}

public class Band
{
    public int Id { get; set; }
    public string Name { get; set; }
    public Genre Genre { get; set; }
}

在现实世界中,这些可能要复杂得多,具有各种业务逻辑,可能还有一些验证调用等.

如果我公开了一个公共API,我的DTO可能看起来非常像这个例子,没有任何业务逻辑.

如果我还有一个MVC网络应用程序,我想要显示一个事件列表,我可能想要一个看起来像这样的视图模型：

public class EventViewModel
{
    public int Id { get; set; }
    public string Name { get; set; }
    public DateTime EventDate { get; set; }

    public int HeadlinerId { get; set; }
    public string HeadlinerName { get; set; }
    public int OpenerId { get; set; }
    public string OpenerName { get; set; }
}

通常,人们只需使用引用来提取完整的域实体,然后使用映射实用程序来水合视图模型.

但是,假设我有成千上万的记录.现在,ORM可能会创建一个查询风暴来填充完整的引用对象(这可能比这个示例复杂得多,有自己的引用).性能开始严重受损并不需要很长时间.

问题是什么？

我知道我不是唯一遇到这个问题的人,所以我很想知道人们如何维护分层应用程序,同时仍然需要在生成代表相同底层域信息的多个对象时保持性能.

让两个Event-ish对象表示相同的持久化数据感觉不对,但同时看起来持久层似乎不应该知道DTO或视图模型,否则争取分离的重点是什么？

那你怎么解决这个问题呢？持久性是否了解域实体的严格,详细表示以及这些实体中数据的轻量级描述？是那些重量较轻的描述DTO或某些域实体精简版？

解决方法:

您的问题没有简单的答案,因为它实际上取决于您希望通过您的架构实现的目标.这是一种经典的架构权衡.

这也意味着你需要自己决定.确保您了解每种方法的优缺点,然后决定您的项目.以下是优缺点列表：

严格分离的优点

>能够根据特定层的职责调整和调整结构.例如,持久性DTO可以以不同于域实体的方式存储数据以支持复杂的查询案例.
>能够支持数据迁移案例.使用单独的持久性DTO,您可以选择加载“旧”DTO格式并将其转换为“新”域实体.
>简化DTO返回外部世界的能力,例如：通过API.这在使用DDD时几乎总是有意义,因为使用DDD通常表明域很复杂.
>更好地分离开发人员的顾虑.通常,严格的分层会增加团队并行处理相同功能的可能性,例如：一个在持久性中,一个在域中.
>根据ORM或数据库的功能集,在持久性中直接使用域实体甚至不是一个选项.如果是一种选择,它可能比拥有专用的DTO更复杂.

共享类的优点

>减少相同功能的代码.
>通常更快的开发时间用于新功能.
>更小的概念开销.我认为这是一个小问题,因为DTO和视图模型是众所周知的概念,但它可能是一个问题,取决于团队.

如您所见,我认为性能不是共享方法的优势.主要原因是精心设计的对象到对象映射的数量级比从数据库加载数据的速度快.所以我非常有信心严格分离方法中的性能问题是由于其他问题,而不是分层.

有了以上几点(可能还有更多针对您的环境的内容),您应该能够做出决定.我过去曾使用过这两种方法,但对于一定规模的项目,我总是选择严格的分离方法.

标签：c,architecture,domain-driven-design
来源： https://codeday.me/bug/20190623/1270878.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。

ICode9

c# – 域名实体或持久性是否应该生成DTO？