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

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

内容导读

互联网集市收集整理的这篇技术教程文章主要介绍了c# – 域名实体或持久性是否应该生成DTO？，小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含3379字，纯文字阅读大概需要5分钟。

内容图文

当谈到具有现代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# – 域名实体或持久性是否应该生成DTO？全部内容，希望文章能够帮你解决c# – 域名实体或持久性是否应该生成DTO？所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错，欢迎将互联网集市网站推荐给程序员好友。

内容备注

版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 gblab@vip.qq.com 举报，一经查实，本站将立刻删除。

内容手机端

扫描二维码推送至手机访问。

本文链接：https://qyyshop.com/info/794972.html

来源：【匿名】