精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
---|---|
作者 | 正文 |
发表时间:2005-03-08
我再仔细阅读了一下peaa,还是觉得rich domain object 需要知道dao,可能我的例子举的不好:但是至少就lazy load 这一点还是需要访问dao的.
再者同意robbin说的的对象模型的丰富的表现力.但是要把这个表现力转变成生产力才行啊!我那道了个order 要orderitem,不能不来个null把,orderitem要看product 不能出来null把,什么时候拿到初始化,一次性load还是跳出去请dao来help? 下面是martin 的论点: 引用 Handling Finders In order to work with an object, you have to load it from the database. Usually the presentation layer will initiate things by loading some initial objects. Then control moves into the domain layer, at which point the code will mainly move from object to object using associations between them. This will work effectively providing that the domain layer has all the objects it needs loaded into memory or that you use Lazy Load (200) to load in additional objects when needed. On occasion you may need the domain objects to invoke find methods on the Data Mapper. However, I've found that with a good Lazy Load (200) you can completely avoid this. For simpler applications, though, may not be worth trying to manage everything with associations and Lazy Load (200). Still, you don't want to add a dependency from your domain objects to your Data Mapper. You can solve this dilemma by using Separated Interface (476). Put any find methods needed by the domain code into an interface class that you can place in the domain package. |
|
返回顶楼 | |
发表时间:2005-03-08
你的意思就是承认除了lazy loading之外domain object不添加任何业务方法是完全可行的了吧。好,那么来说lazy loading,其实这个问题,论坛已经讨论n遍了,我只好再复述一遍。分两种情况:
1、纯Web应用,使用OpenSessionInView模式。这种情况下lazy不lazy对你来说完全透明,domain object完全不需要添加任何业务方法。 2、带有远程客户端访问的的系统,这种情况无法使用OpenSessionInView模式,所以就像你引用的Martin Fowler一段话所说的那样来做,“using Separated Interface ” List orderItems = orderDao.getOrderItems(order);; 而不是直接通过domain object来取: orderItems = order.getOrderItems();; 所以不管lazy不lazy,domain object不应该形成对Dao接口的反向依赖,只应该是Dao接口对domain object的单向依赖。 |
|
返回顶楼 | |
发表时间:2005-03-08
怎么觉得看的稀里糊涂呢?
觉得应该是Domain Model-->Data Source Layer才是吧? Domain Model充当了业务逻辑层,Data Source Layer充当了数据源层,Domain Model由Domain Object组成,而Data Source Layer呢可能是DAO+PO的组合,固然在很多系统中,这个PO都和Domain Object一致,在Domain Model上经常借助Application Controller等来通过对于不同Domain Object的调用来实现业务逻辑流程 |
|
返回顶楼 | |
发表时间:2005-03-08
robbin 写道 首先来说,文件系统和数据库两回事,没有什么类比关系,这个例子也举得不好,何况你的DAO设计的也不合理。
引用 1)建立file时。 2)修改file.name时。 3)在folder间移动file时。 1) File file = new File();; file.setFolder(folder);; file.setName(name);; file.set.....; fileDao.addFile(file);; 2) file.setName(newFileName);; fileDao.updateFile(file);; 3) file.setFolder(newFolder);; fileDao.updateFile(file);; 我感觉robbin没完全理解我的意思。 从这些代码中看不出业务限制是在那里实现的,难道是要在fileDao中各个方法里面进行name是否重复的判定么?在DAO里面实现业务限制? 另外解释一下,这里只是举个例子,其实可以把这个例子想象成一个基于数据库的文件系统的设计。 希望robbin能继续这个讨论。 |
|
返回顶楼 | |
发表时间:2005-03-08
引用 这种情况下lazy不lazy对你来说完全透明! 问题时你这样做: 引用 List orderItems = orderDao.getOrderItems(order); 根本不透明阿,倒是我的方法比较透明一点,order.getItems();是不是lazy的order的用户根本不需要知道.order.getProductsInfo();也一样更加自然 order 拥有它的数据和它的行为。 引用 You can solve this dilemma by using Separated Interface (476). Put any find methods needed by the domain code into an interface class that you can place in the domain package. interface class that you can place in the domain package! |
|
返回顶楼 | |
发表时间:2005-03-08
我始终认为rich domain object 的最大的优势就是应该自由在对象间导航,让他的客户端,不考虑对象是不是从数据库得到!order 对象里面 肯定有个集合时 orderitem 的集合,用户在拿到order后拿到他的orderitems 很自然,并不需要知道他是否被 orderADO调用过,对吧?难道每次先:
if Order.getItems()!= null orderADO.getItems(order)? 这样似乎很不透明阿 |
|
返回顶楼 | |
发表时间:2005-03-08
pig345 写道 robbin 写道 首先来说,文件系统和数据库两回事,没有什么类比关系,这个例子也举得不好,何况你的DAO设计的也不合理。
引用 1)建立file时。 2)修改file.name时。 3)在folder间移动file时。 1) File file = new File();; file.setFolder(folder);; file.setName(name);; file.set.....; fileDao.addFile(file);; 2) file.setName(newFileName);; fileDao.updateFile(file);; 3) file.setFolder(newFolder);; fileDao.updateFile(file);; 我感觉robbin没完全理解我的意思。 从这些代码中看不出业务限制是在那里实现的,难道是要在fileDao中各个方法里面进行name是否重复的判定么?在DAO里面实现业务限制? 另外解释一下,这里只是举个例子,其实可以把这个例子想象成一个基于数据库的文件系统的设计。 希望robbin能继续这个讨论。 什么叫做业务限制?什么叫做name是否重复的判定?不知道你在说什么。 我给出来的代码就是你上面给出来的代码的修正。 |
|
返回顶楼 | |
发表时间:2005-03-08
frankensteinlin 写道 引用 这种情况下lazy不lazy对你来说完全透明! 问题时你这样做: 引用 List orderItems = orderDao.getOrderItems(order); 根本不透明阿,倒是我的方法比较透明一点,order.getItems();是不是lazy的order的用户根本不需要知道.order.getProductsInfo();也一样更加自然 order 拥有它的数据和它的行为。 引用 You can solve this dilemma by using Separated Interface (476). Put any find methods needed by the domain code into an interface class that you can place in the domain package. interface class that you can place in the domain package! 一个class它放在哪个package里面这根本就不重要!你认为很重要吗? |
|
返回顶楼 | |
发表时间:2005-03-08
if Order.getItems();!= null orderADO.getItems(order);? 这样肯定不透明吧 为什么? 因为 order 无法确定自己的成员变量的状态!哪怕它是private的(orderItems), 我认为我上传得martin的paee中的图很清楚了: domain object 保持对 dao interface 的引用 dao interface 是实现可以另外考虑 |
|
返回顶楼 | |
发表时间:2005-03-08
robbin 写道 什么叫做业务限制?什么叫做name是否重复的判定?不知道你在说什么。 我给出来的代码就是你上面给出来的代码的修正。 pig345 写道 DomainObject: folder 1 ---- * file (这里仅仅是用Folder和File做个比喻,因为是计算机上最常见的东西,容易理解) 业务限制: file.name 在 folder 中唯一(同一目录中不能包含相同名字的文件)。 robbin为什么不能仔细看一下帖子呢?我称之为业务限制也许不妥,如果有更好的说法,请指正。 另外,我上面代码2里实际的意思是要在setName和setFolder里面判定name是否重复,如果重复的话,就要抛相应异常。 |
|
返回顶楼 | |