首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

您应该将哪些对象从数据访问层返回到业务层和n层系统

在云计算领域,数据访问层(Data Access Layer, DAL)是一个关键的组件,它负责处理数据库和其他数据源的访问。业务层(Business Layer, BL)和n层系统(n-Tier Architecture)是应用程序的其他组件,它们负责处理业务逻辑和交互。

在设计应用程序时,应该将哪些对象从数据访问层返回到业务层和n层系统?这取决于应用程序的需求和设计。以下是一些建议:

  1. 数据传输对象(Data Transfer Object, DTO):这些对象通常用于在数据访问层和业务层之间传递数据。它们通常包含属性,但不包含方法。
  2. 数据访问对象(Data Access Object, DAO):这些对象用于封装数据访问层的逻辑。它们通常包含方法,用于执行数据库操作,例如查询、插入、更新和删除。
  3. 业务对象(Business Object, BO):这些对象用于封装业务逻辑。它们通常包含方法,用于执行业务操作,例如验证数据、计算值和处理事务。
  4. 服务对象(Service Object, SO):这些对象用于封装服务层的逻辑。它们通常包含方法,用于执行服务操作,例如与其他系统通信或处理文件操作。

总之,应该将哪些对象从数据访问层返回到业务层和n层系统取决于应用程序的需求和设计。通常,应该将数据传输对象、数据访问对象、业务对象和服务对象从数据访问层返回到业务层和n层系统。

页面内容是否对你有帮助?
有帮助
没帮助

相关·内容

软件架构设计分层模型构图思考

架构本身也一个业务功能实现的完整对应,在数据访问处理数据获取持久化操作,在业务逻辑业务规则进行处理,在界面展现进行相应的前端展现用户交互。...业务逻辑更名为领域自然是题中应有之义,而将数据访问更名为基础设施(Infrastructure Layer),则突破了之前数据库管理系统的限制,扩大了这个负责封装技术复杂度的基础层次的内涵。...当然,也有融合了领域模型传统三架构思路后的技术架构如下: 领域业务逻辑 在领域建模的一个核心是领域模型,领域模型不再是一个个独立的数据库表或数据对象,而是一个业务对象或领域对象。...如果回到微服务中台架构下,这个应用拆分更加必要,即通过应用来下沉共性的服务组合组装逻辑,这个逻辑和协同不应该属于任何一个前端应用。...单个应用功能架构 注意应用功能架构完全是重点描述应用系统具备哪些功能,一个功能究竟是采用什么三技术架构实现并不用关心。因此功能架构不应该体现数据,逻辑,技术点这些内容。

44410

软件架构设计分层模型构图思考

架构本身也一个业务功能实现的完整对应,在数据访问处理数据获取持久化操作,在业务逻辑业务规则进行处理,在界面展现进行相应的前端展现用户交互。...业务逻辑更名为领域自然是题中应有之义,而将数据访问更名为基础设施(Infrastructure Layer),则突破了之前数据库管理系统的限制,扩大了这个负责封装技术复杂度的基础层次的内涵。...当然,也有融合了领域模型传统三架构思路后的技术架构如下: 领域业务逻辑 在领域建模的一个核心是领域模型,领域模型不再是一个个独立的数据库表或数据对象,而是一个业务对象或领域对象。...如果回到微服务中台架构下,这个应用拆分更加必要,即通过应用来下沉共性的服务组合组装逻辑,这个逻辑和协同不应该属于任何一个前端应用。...单个应用功能架构 注意应用功能架构完全是重点描述应用系统具备哪些功能,一个功能究竟是采用什么三技术架构实现并不用关心。因此功能架构不应该体现数据,逻辑,技术点这些内容。

45930
  • 软件架构设计分层模型构图思考

    架构本身也一个业务功能实现的完整对应,在数据访问处理数据获取持久化操作,在业务逻辑业务规则进行处理,在界面展现进行相应的前端展现用户交互。...业务逻辑更名为领域自然是题中应有之义,而将数据访问更名为基础设施(Infrastructure Layer),则突破了之前数据库管理系统的限制,扩大了这个负责封装技术复杂度的基础层次的内涵。...当然,也有融合了领域模型传统三架构思路后的技术架构如下: ? 领域业务逻辑 在领域建模的一个核心是领域模型,领域模型不再是一个个独立的数据库表或数据对象,而是一个业务对象或领域对象。...如果回到微服务中台架构下,这个应用拆分更加必要,即通过应用来下沉共性的服务组合组装逻辑,这个逻辑和协同不应该属于任何一个前端应用。...单个应用功能架构 注意应用功能架构完全是重点描述应用系统具备哪些功能,一个功能究竟是采用什么三技术架构实现并不用关心。因此功能架构不应该体现数据,逻辑,技术点这些内容。

    1.9K20

    DDD实战之二:看看代码结构长啥样

    的那些 POJO 对象如 Order 等,没有任何业务行为的封装(比如:Order 类应该自己生成自己的订单号、提货号等),只有属性而没有行为的对象,就是“贫血”对象,基于“贫血”对象实现的业务逻辑代码...业务子领域针对某个具体的软件系统来说,是可以从业务角度判断出哪些必须建设为软件的核心竞争力、哪些则可以作为次要模块甚至通过外包来实现。...在 DDD 的系统架构中,限界上下文(具体概念介绍见后面,这里你只需要理解为它类似于子系统业务模块划分就好)是可以根据“业务子域”不是核心,而分为“基础业务价值”。...典型的 3 类外部资源请求有:访问数据持久(关系或非关系数据库)、调用别的限界上下文服务(在微服务架构中,往往是 RPC 远程调用)、向别的限界上下文发布消息。...因为,我们是不用限界上下文内部的“领域”的内部对象结构“泄露”到外部的,所以我们必须要有这个“发布语言”

    73920

    如何运用领域驱动设计 - 存储库

    通过一个众所周知的接口来提供访问。提供添加删除对象的方法,用这些方法来封装在数据存储中实际插入或删除数据的操作。...通过返回一个IQueryable对象,甚至可以业务查询逻辑直接放到应用,这样想怎么操作就怎么操作。 请注意!!!这非常的危险!!!! 您可能会问了:“我平时所接触的框架或者仓储不都是这样写的吗?...可以实现我任何的业务查询,爽歪歪。” 但是这样写正在逐渐丧失存储库原有的作用。回到开篇提到的一个问题:假如使用了EF这样的ORM框架,为什么还需要嵌套一仓储呢?...具有领域意图的东西我们都应该领域,而类似于数据库的访问实现这类基础架构应该放在基础设施。所以可以看出我们抽象出来的仓储接口是应该放在领域的,而仓储的实现可以放在基础设施 。...还有一种方法是查询单独划分为应用系统的一个分支,修改(命令)单独划分为另外一个分支来操作领域对象。这是DDD的另外一种模式,可能已经听过它的英文简写了:CQRS。

    97430

    架构之道:界定的责任与模块划分

    例如,假设希望向架构中包含业务组件的通用服务组件添加一个共享服务(例如,数据字符串工具类或审计日志记录类)。...如果没有这个独立的,架构上没有明确的机制来限制表示对这些共享服务的访问,这会使限制这种访问变得困难。在这个示例中,新的服务很可能位于业务下方,以表示该服务中的组件不应该直接表示访问。...客户代理模块负责了解业务哪些模块能够处理该请求,如何到达这些模块,以及需要哪些数据(也就是契约)。在业务,客户对象负责汇总业务请求所需的所有信息(在这个案例中,就是获取客户信息)。...这个模块会调用持久化中的客户数据访问对象(DAO)模块,以获取客户数据,同时还会调用订单DAO模块,以获取订单信息。这些模块接着会执行SQL语句,以检索相应的数据,并将数据传递回业务中的客户对象。...微软平台的视角来看,客户端界面可以是一个使用.NET框架的ASP(活动服务器页面)模块,用于访问业务中的C#模块,而客户订单数据访问模块可以实现为ADO(ActiveX Data Objects)

    10710

    整洁架构、DDD CQRS 简介

    由于不同的编排操作,它将数据传输对象(DTO) 传递到表示。同样,它还使用注入的基础设施接口与操作系统其他外部资源进行通信。 ◆ 外围 ◆ 持久 持久包含 应用中声明的持久性接口的实现。...它还包含专门的持久性模型(数据访问)类,这些类可能是也可能不是数据库表的镜像(特别是如果使用对象关系映射器,又名 ORM),或者可能代表数据库查询的投影。...但是,已经丧失了 CQRS 提供的好处,因为它抽象了跨边界的组件之间的通信过程本身。CQS 原则指出: 查询系统数据的高级操作不应该产生任何副作用——即修改状态。这些称为查询。...查询通过 DTO 数据回到表示。 修改系统的高级操作不应返回数据。这些应该会产生副作用,修改系统的状态,然后完成。这些被称为命令。...如果需要在命令逻辑中数据库中检索数据,那么应该简单地使用 ORM 或其他方法直接查询数据库。请注意,这是一个典型的例子,其中必须违反某些原则才能维护其他原则。

    3.9K20

    DTO 的替代品!!

    我相信(并且仍然相信)它应该成为过去。然而,它的使用似乎仍然很普遍。 我不否认转换数据有一些正当理由。...但是,传统的 DTO 流程还有其他替代方案: 服务返回一个业务对象 请注意,我之前从事的项目,我们直接 BO 映射到数据库读取的实体。... BO 转换为表示中的 DTO 表示返回 DTO 1 返回实体本身 当实体的属性是需要显示的属性的超集时,不需要聚合其他属性。实体转换为 DTO 不仅是矫枉过正。它会阻碍性能。...2 JPA 投影 我们在特定情况下请求特定数据。因此,当调用到达数据访问时,所需数据的范围是完全已知的:执行适合此范围的 SQL 查询是有意义的。 为此,JPA 提供了预测。...5 结论 当业务模型演示模型之间存在差距时,很容易回到古老的“模式”,例如 DTO。但是,上述任何替代方案都可能更相关。

    1.1K30

    IT工程师必看系列:什么是数据中心冗余?

    最大化正常运行时间应该是每个数据中心的首要任务,无论它们是小型的还是超大规模的,为了让数据中心持续运行,冗余系统计划是必须的。 什么是数据中心冗余?...如果由于恶劣天气、停电或组件故障而导致停机,数据中心备份组件发挥作用,以保持整个系统的运行。 为什么数据中心冗余很重要? 无论是意外的还是计划的,企业都必须增加正常运行时间并更快地停机中恢复。...冗余也是衡量数据中心可靠性、性能可用性的关键因素。Uptime Institute 提供了一个等级分类系统,根据四个不同的等级对数据中心进行认证 - 第 1 、第 2 、第 3 第 4 。...如果数据中心设施处于满负荷状态并且出现硬件故障、定期维护或意外中断,那么关键任务应用程序就会受到影响。使用 N 设计,任何中断都会使的企业无法访问数据,直到问题得到解决。...总之,冗余模型没有对错之分,因为它取决于一系列因素,例如业务目标、预算 IT 环境。请咨询数据中心提供商或与的 IT 团队讨论,以找出最适合的选择。

    77920

    对话Apache Hudi VP,洞悉数据湖的过去现在未来

    我们Vertica开始,但是随着数据量的增长,我们意识到需要一个数据湖,我们使用Spark所有初始数据转储到数据湖中,然后原始数据本地仓库中移出。...因此可以自由选择,并且可以实际控制哪些数据回到我之前说的那样,此原始原始数据几乎没有增加数据延迟,所有原始数据都非常快地流入数据湖,这就是在公司中进行的任何派生数据计算的起点。...Q9:如果系统可以Hudi受益但没有使用Hudi,它们面临哪些挑战呢? VC:让我们来一个没有Hudi的数据湖。...提取一样,这些事件写成类似Avro文件行存,这就是布置原始数据的方式。...因此我认为一个高性能高度可伸缩的元存储,内部有Snowflake或BigQuery或redshift之类的东西,我们需要构建类似的东西,我认为这两者放在一起真正释放我们的愿景,那就是所有数据应该非常快地到达

    75320

    PHP8 对象、模式实践(六)

    本章涵盖几个关键主题: 架构概述:介绍通常构成企业应用的 注册表模式:管理应用数据 表示:用于管理响应请求以及向用户呈现数据的工具 业务逻辑:了解系统的真正目的,即解决业务问题...实际上,这一视图层通常被合并成一个单一的表示。尽管如此,显示的角色应该与请求处理业务逻辑调用的角色严格分开。 业务逻辑负责处理请求的业务。它执行任何所需的计算并整理结果数据。...数据系统的其余部分与保存获取持久信息的机制隔离开来。在一些系统中,命令控制使用数据来获取它需要处理的业务对象。在其他系统中,尽可能隐藏数据。 那么这样划分一个系统有什么意义呢?...一个答案是在系统对象对象传递信息:负责处理请求的控制器对象业务逻辑中的对象,最后到负责与数据库对话的对象。 这是完全可行的。...这是一种形式的平面,在这里,业务问题发挥出它们的本性,不受令人讨厌的物质问题(如数据网页)的阻碍。 如果这看起来有点华丽,让我们回到现实吧。领域模型是系统的真实世界参与者的表示。

    18910

    「领域驱动设计」DDD,六边形架构,洋葱架构,整洁架构,CQRS的整合架构

    如果阅读了本系列以前的文章,那么本文的内容可能更有意义。 今天的帖子是关于我如何所有这些部分组合在一起的,我似乎应该给它起个名字,我称它为显式架构(Explicit Architecture)。...系统的基本模块 工具 工具交付机制连接到应用程序核心 端口 主适配器或驱动适配器 辅助或被驱动适配器 控制反转 应用程序的核心组织 域服务 域模型 应用程序 领域 组件 组件之间共享的数据存储...每个组件隔离数据存储 解耦的组件 触发逻辑在其他组件 其他组件获取数据 控制流 系统的基本模块 我首先回顾一下EBI端口及适配器架构。...领域 再往里,我们有域。这个中的对象包含数据操作数据的逻辑,这是特定于域本身的,它独立于触发逻辑的业务流程,它们是独立的,完全不知道应用。...持有该数据副本的组件侦听该域事件,并相应地更新其本地副本。 控制流 正如我上面所说的,控制流当然是用户到应用程序核心,再到基础设施工具,最后回到应用程序核心,最后回到用户。

    2K30

    领域驱动设计简介(上篇)

    的软件生涯中,您可能已经遇到过许多这些想法,特别是如果您是OO语言的经验丰富的开发人员。但将它们一起应用允许构建真正满足业务需求的系统。...毕竟,当你想到它时,弄清楚BC之间的关系是非常具有战略重要的:我的系统依赖哪些上游系统,我是否容易与它们集成,我是否有利用它们,我相信它们吗?...下游也是如此:哪些系统将使用我的服务,如何将我的功能作为服务公开,他们是否会对我有利?误解了这一点,的应用程序可能很容易失败。 六边形 现在让我们转向内部并考虑我们自己的BC(系统)的架构。...如果表现有单独的存储空间中(比如手机终端),应用也充当表现领域之间的中介。表现通常处理领域对象或其他对象数据传输对象或DTO)的可序列化表示,通常每个“视图”一个。...如果我们想测试我们的应用程序肯定是这样的: a、例如,FitNesse等工具允许我们最终用户的角度验证我们系统的行为。但是这些工具通常不会通过表示,而是直接返回到下一,即应用

    39720

    即使是数据驱动型公司也无法充分发挥数据的潜力

    当关键的业务信息驻留在孤立分散的系统中时,检索数据、将其转换为正确的格式以及提取可操作的洞察变得过于耗时资源密集。...尽管领导者尽最大努力在决策过程中依赖数据,但当数据提取变得困难时,许多人会退回到直觉。 治理为数据管理工作增加了另一复杂性,经常让企业需要帮助才能同时实现敏捷性安全性。...用户可以查看与其业务部门无关的数据,并以非结构化的方式共享数据。因此,公司需要了解谁可以访问哪些信息以及数据如何在整个组织中传播,这会导致安全漏洞和合规性问题。...此外,数据虚拟化还提供额外的优势,即通过保留谁访问哪些信息的审计跟踪来支持用户治理,并使您能够根据职位级别职能设置用户访问控制。 2....没有一种万能的连接工具适用于所有场景,因此在寻求微调和执行数据策略时,请考虑独特的基础设施设置、业务目标和合规性法规。数据连接工具应该增强现有的技术堆栈,而不是破坏它。 4.

    12210

    DDD之熵

    貌似回到了怎么区分应用服务与领域服务;还有各处javabean,哪些能复用,谁复用谁 再比如COLA2.0,单从层次依赖图明显形成了循环依赖,落地不了;但作者把repository上移到了application...这就是端口适配器架构,可以算是六边形的简化版,但也整体方向分成了两,对应用与用户接口以及基础设施进行了合并,无论是接受请求,还是输出数据都是gateway 但六边形架构仅仅区分了内外边界,提炼了端口与适配器角色...基础设施:包含 OrderMapper、RabbitEventBus 与 EmailSender,为业务实现提供对应的技术功能支撑,但真正的基础设施访问则委派给系统边界之外的外部框架或驱动器 ----...它的职责与属于应用的入口端口也不同,因为应用的应用服务是对外部请求的封装,相当于是一个业务用例的外观 DDD引入repository放在了领域,一是对应聚合根的概念,二是抽象了数据访问,,但DDD...限界上下文可能不仅限于访问数据库,还可能访问同样属于外部设备的文件、网络与消息队列。

    54020

    嵌入式代码中产生bug的几大原因~

    共享数据抢占的随机时间是造成竞争状况的元凶。但是错误可能并不总是会发生,这使得观察到的症状到根本原因的种族状况跟踪变得异常困难。因此,保持警惕以保护所有共享对象非常重要。...然后,任务B调用套接字功能,该套接字功能调用TCP功能,再调用IP功能,该功能调用以太网驱动程序,该队列数据包B排队并传输。当CPU的控制权返回到任务A时,它将请求传输。...最佳实践:挥发 的关键字应该用于声明每个: 由ISR代码的任何其他部分访问的全局变量; 由两个或多个RTOS任务访问的全局变量(即使已阻止了这些访问中的竞争条件); 指向内存映射外设寄存器(或一组或一组寄存器...损坏的性质不当行为的时机完全取决于破坏哪些数据或指令以及如何使用它们。重要的是,堆栈溢出到它对系统的负面影响之间的时间长短取决于使用阻塞位之前的时间。...可以通过调用free()或使用 delete 关键字将不再需要的数据结构的存储返回到堆中。理论上讲,这使该存储空间可用于后续分配期间的重用。

    73420

    DDD的基础设施到底在哪里

    基础设施还能够通过架构框架来支持4个层次间的交互模式。” DDD的分层架构看,领域对基础设施产生了依赖,这违背了依赖倒置原则:上层模块不应该依赖于下层模块,而应该依赖于下层模块的抽象。...如果Repository对领域对象的操作视为对对象集合的操作,Repository放到领域也就顺理成章了。...可是对于一个业务系统而言,领域不仅仅需要访问数据库,如果需要访问消息队列传递消息呢,需要访问文件呢,需要网络通信呢?难道要将所有访问外部资源的接口都归属到领域吗?这明显不合理。...由于限界上下文是业务能力的纵向切分,在其边界内,不仅包含领域,也包含了网关,甚至其逻辑边界还包含它要访问数据库。若回到基础设施的语义,也就认为限界上下文包含基础设施。...由于限界上下文是业务能力的纵向切分,一个自治的限界上下文,就必须包含它所需要的完整的内容,如果每个限界上下文都看做是一个独立的子系统,在系统层次似乎就没有基础设施的必要了。

    1.3K10

    「首席看软件架构」DDD,六边形,洋葱的,干净的,CQRS的整合架构

    系统的基本模块 工具 工具交付机制连接到应用程序核心 端口 主适配器或驱动适配器 辅助或被驱动适配器 控制反转 应用程序的核心组织 域服务 域模型 应用程序 领域 组件 组件之间共享的数据存储...每个组件隔离数据存储 解耦的组件 触发逻辑在其他组件 其他组件获取数据 控制流 系统的基本模块 我首先回顾一下EBI端口及适配器架构。...它们都明确区分了哪些代码是应用程序内部的,哪些是外部的,以及哪些用于连接内部外部代码。...领域 再往里,我们有域。这个中的对象包含数据操作数据的逻辑,这是特定于域本身的,它独立于触发逻辑的业务流程,它们是独立的,完全不知道应用。 ?...持有该数据副本的组件侦听该域事件,并相应地更新其本地副本。 控制流 正如我上面所说的,控制流当然是用户到应用程序核心,再到基础设施工具,最后回到应用程序核心,最后回到用户。

    5.1K22

    【企业架构】在 Powerpoint 中建模企业架构

    为了清楚起见,我留下了,但应该使用对您有意义的名称相应地标记元素。 下一步将是创建一个交互图,其中定义了业务参与者连接。所以基本上你只需要根据数据流、交互依赖关系来连接你的元素。...了解与我们对解决方案的要求相匹配的模式最佳实践应该可以指导我们找到正确的解决方案。最重要的是,我们清楚哪些组件应该由使能技术提供,哪些实际上是我们自己解决方案范围的一部分。...为这些依赖项添加数据对象技术接口有助于我们了解全局。 技术 在描述了业务服务的功能之后,我们需要开始设计具体的操作环境。位置为我们提供了所需网络架构的提示。...可以有多层节点、技术位置,以便我们可以根据需要尽可能详细地描述地理分布要求、虚拟化容器托管。 我喜欢应用程序组件开始,因为应该应用程序级图表中准备好它们。...然而,目前只创建了基本的业务、应用程序技术形状。用策略迁移对象填充整个调色板仍然是一项简单的工作。

    1.1K30

    数据模型架构设计规范

    具体仓库的分层情况需要结合业务场景、数据场景、系统场景进行综合考虑。 数据分类架构 该数据分类架构在ODS分为三部分:数据准备区、离线数据准实时数据区。...公共汇总粒度事实: 以分析的主题对象为建模驱动,基于上层的应用产品的指标需求,构建公共粒度的汇总指标事实表,以宽表化手段来物理化模型。...按业务过程划分: 当一个数据域由多个业务过程组成时,命名时可以按业务流程划分。 业务过程是数据分析角度看客观存在的或者抽象的业务行为动作。...模型设计的基本原则 高内聚低耦合 一个逻辑物理模型由哪些记录字段组成,应该遵循最基本的软件设计方法论中的高内聚低耦合原则。...主要从数据业务特性访问特性两个角度来考虑:业务相近或者相关的数据、粒度相同数据设计为一个逻辑或者物理模型;高概率同时访问数据放一起,低概率同时访问数据分开存储。

    96021
    领券