论坛首页 Java企业应用论坛

再乱弹一下“领域模型与数据访问接口的依赖问题”

浏览 22720 次
该帖已经被评为精华帖
作者 正文
   发表时间:2005-11-09  
不考虑效率问题的前提下:我的观点是
领域模型就是领域模型:它不依赖于数据访问接口的
javaeye好像以前主要是讨论hibernate并以此命名的吧,诸位怎么没有发掘到hibernate这样的ORM给我带来的最具革命性的变化就是:
透明的持久化
  Country coun=order.getCountry();;
  PassportType type =count.getPassPortTypes();;

hibernate给我们的重要的财富就是内建立了对象图,对象之间的导航是不需要显示的数据连结的。这样领域模型为什么要依赖数据防卫接口呢??

关键的步骤是:要将对象注册到对象图中去如:Order order =(Order)session.getObjectByID(orderID) session.save()....等等

这一步放在哪里?service 层!剩下的就是领域模型之间自己交互的事情了!
不存在依赖关系
0 请登录后投票
   发表时间:2005-12-01  
frankensteinlin 写道
不考虑效率问题的前提下:我的观点是
领域模型就是领域模型:它不依赖于数据访问接口的
......
关键的步骤是:要将对象注册到对象图中去 如:Order order =(Order)session.getObjectByID(orderID) session.save()....等等

这一步放在哪里?service 层!剩下的就是领域模型之间自己交互的事情了!
不存在依赖关系


如果你的领域对象的create/update/delete有若干的限制条件(须查询数据库才能确定,比如:name字段在某些条件下不能重复),或者领域对象的某个计算方法(须查询数据库才能进行),必须依赖数据库数据可怎么办?你如何选择:

a)将这些数据访问逻辑和业务处理逻辑(从domain移出来)放到service层(domain Object 还是domain么?)。

b)将数据访问逻辑放到service层,业务处理逻辑放在domainObject (基本上也就是分散业务逻辑,如果只是逻辑实现细节有修改,也肯定要涉及到两个层)。

c)将数据访问逻辑放到Dao层,业务处理逻辑放在domainObject,让domainObject使用 (也就是依赖于)Dao。
0 请登录后投票
   发表时间:2005-12-02  
引用

软件的业务模型在很大程度上要受到技术发展水平的制约。在O/R Mapping工具流行以前,甚至连贫业务的领域模型也无法在项目中使用。随着O/R Mapping工具的流行,我们开始强调领域模型也放入业务逻辑。但是正如你提到的,我也承认,O/R Mapping下面的领域模型仍然是贫业务的领域模型。这倒不是因为我们不愿意放入更多的业务逻辑,而是受到技术发展水平的制约。具体来说,就是受到了数据库资源打开关闭和应用事务管理横切面的极大制约。如果技术的发展可以突破这种制约(例如更加智能,完全透明化的持久机制和全自动的资源管理和事务管理),我相信实体领域模型(用代码实现的领域模型)会更加富含业务逻辑,会更加贴近概念领域模型。


这个观点和我的观点一致,现在的ORMApping工具还没牛到持久化操作完全能够完全透明,性能上更不能实现。

 要让业务类完全脱离dao只会让业务类贫血,现在可行的是让dao尽量的薄
0 请登录后投票
论坛首页 Java企业应用版

跳转论坛:
Global site tag (gtag.js) - Google Analytics