该帖已经被评为精华帖
|
|
---|---|
作者 | 正文 |
发表时间: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 层!剩下的就是领域模型之间自己交互的事情了! 不存在依赖关系 |
|
返回顶楼 | |
发表时间: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。 |
|
返回顶楼 | |
发表时间:2005-12-02
引用 软件的业务模型在很大程度上要受到技术发展水平的制约。在O/R Mapping工具流行以前,甚至连贫业务的领域模型也无法在项目中使用。随着O/R Mapping工具的流行,我们开始强调领域模型也放入业务逻辑。但是正如你提到的,我也承认,O/R Mapping下面的领域模型仍然是贫业务的领域模型。这倒不是因为我们不愿意放入更多的业务逻辑,而是受到技术发展水平的制约。具体来说,就是受到了数据库资源打开关闭和应用事务管理横切面的极大制约。如果技术的发展可以突破这种制约(例如更加智能,完全透明化的持久机制和全自动的资源管理和事务管理),我相信实体领域模型(用代码实现的领域模型)会更加富含业务逻辑,会更加贴近概念领域模型。 这个观点和我的观点一致,现在的ORMApping工具还没牛到持久化操作完全能够完全透明,性能上更不能实现。 要让业务类完全脱离dao只会让业务类贫血,现在可行的是让dao尽量的薄 |
|
返回顶楼 | |