【问题标题】:DTO DAO POCO BODTO DAO POCO BO
【发布时间】:2010-11-15 06:13:51
【问题描述】:

实际上,我对这些术语以及它们之间的关系感到很困惑。阅读有关他们每个人的内容,但我不了解工作流程..

DTO - 数据传输对象 - 传输值的对象
BO 业务对象 - 领域模型中的对象。用于制作业务逻辑的对象
POCO - 不知道,我已经阅读了 wiki 上的定义,但什么都不懂
DAO——数据访问对象——映射DB表的对象?

有人可以帮我带点灯吗?

【问题讨论】:

  • 最佳。标题。曾经。 :)

标签: architecture domain-driven-design design-patterns


【解决方案1】:
  • DTO:数据传输对象,用于在松耦合服务之间传输数据
  • POCO:普通的旧 Clr 对象,普通的 CLR 对象不使用任何属性或所需的继承来充当 DAO/DTO
  • BO:业务对象,包含业务逻辑,用于解决方案的业务逻辑部分
  • DAO:数据访问对象,用于从您的数据库中传输数据

因此,常规工作流程是从服务请求数据,这些数据作为 DTO 发送到您的应用,您将其转换为 BO 以对其进行操作,然后将其作为 DTO 或在将其转换为 DAO 存储后发送回它在数据库中。

您使用不同的对象来区分这 3 种类型之间的关注点,BO 不需要知道它是使用数据库还是服务持久化的。

【讨论】:

  • 说得好。简短但有效。
  • 我唯一想念的是,如果您的 BO 逻辑需要加载数据,该怎么办?它如何访问 DAO?
  • @pihentagy 这就是 dal 所做的。
  • 只是作为补充:你可以将 DAO 视为 BO 和数据库之间的 DTO
【解决方案2】:

基于时间线的脚手架:

  • 批处理 => 存储过程 => “普通旧 clr 对象” => npmagenda

  • Socket => ODBC => "数据访问对象" => NoSQL

  • CSV => XML => “数据传输对象” => JSON

  • FTP => CGI => “业务对象” => AJAX

参考文献

【讨论】:

    猜你喜欢
    • 2011-01-06
    • 2020-04-20
    • 2011-06-05
    • 1970-01-01
    • 2012-04-10
    • 2011-04-02
    • 2014-03-30
    • 2013-02-02
    • 2010-09-30
    相关资源
    最近更新 更多