业务层——跨越边界传输数据

最新推荐文章于 2024-02-25 05:00:00 发布

Mr___Ray

最新推荐文章于 2024-02-25 05:00:00 发布

阅读量1k

点赞数

本文链接：https://blog.csdn.net/Star_Inori/article/details/85054190

版权

本文探讨了在分层架构中如何处理跨越边界的数据传输，强调了数据流在逻辑层和物理层之间的挑战。文章介绍了领域实体在不同层的作用，指出使用数据传输对象（DTO）的优点和潜在问题，如AutoMapper的使用和IQueryable对象的角色。总结强调正确做事（业务层关注）和做事正确（表现层关注）的平衡，提倡领域建模和DDD方法在提升业务层效率中的价值。

摘要由CSDN通过智能技术生成

跨越边界传输数据

物理层意味着需要跨越的物理边界，不管是进程边界还是机器边界。跨越边界是一个昂贵的操作。触及远程物理机器的代价比触及同一台机器的另一个进程的更高。一个可以参考的经验法则是跨越进程边界的调用比对应的进程内调用要慢100倍。如果要通过网络传输才能到达端点的话就更慢了。
一个调用是如何通过网线跨越边界的？轻装传输？还是背负一切传输？选择最适合的方式跨越边界（逻辑的或物理的）传输数据是应用程序的业务部分要解决的另一个设计问题。

分层架构里的数据流

在这里插入图片描述
上图(跨越分层架构各层的数据流的示意图)展示了分层架构里的一个相对抽象的数据流。

数据从用户界面以InputModel的形式穿过应用程序层。
根据被请求的操作，应用程序层可能需要使用InputModel的内容创建领域实体（比如说，从提供的信息创建一个新的订单）。
在分层的领域模型系统里，持久化通常意味着把领域实体转换成物理数据模型（通常是关系型数据模型）。
在回来的路上，在请求查询时，从数据模型读到的内容首先会被转换成领域实体图，然后适配进视图模型给用户界面渲染。

这4种模型在逻辑上都是不同的，但有时候它们可能是重合的。领域模型可以直接持久化到基础设施层，在这种意义上，领域模型和数据模型通常是相同的。在ASP .NET MVC应用程序里，输入模型和视图模型在控制器操作的GET和POST实现里通常是重合的。在CRUD系统里，所有模型都可能重合，也就是只有一个一一一它将会是MVC模式里的“模型”。

早在20世纪80年代刚被设计出来时，MVC是一个应用程序模式，可以用来架构整个应用程序。那是一体化系统的年代，被端到端创建成单一事务脚本。多逻辑层和多物理层系统的出现改变了MVC的角色，但没有否定它的重要性。MVC仍是一个强大的模式，但单一模型的理念不再有效。MVC里的模型被定义为“在视图里使用的数据"。这意味着今天的MVC基本上是一个表现模式。