JiveJdon Community Forums
在线101人 J道首页 | 论坛首页 | 培训咨询 | 开源框架 | 精华 | 查搜 | 注册 | 登陆 |
首页 » 论坛 » 设计模式、框架和架构
???en_US.forumThreadPrev.name??? 上一主题
Go back to the topic listing   返回主题列表
???en_US.forumThreadNext.name??? 下一主题
这个主题共有 16 回复 / 2 页 [ 1 2 下一页 ]  发表新帖子  回复该主题贴
neo_q

发表文章: 11
注册时间: 2006年04月10日 21:23
解耦合设计的一个困惑,请大家讨论 发表: 2006年04月10日 21:40 回复
我在设计中遇到一个问题!而且我想或许大家也会有类似的困惑,还是我多想了抑或是孤陋寡闻。具体问题如下,简化了分析模型
利用ctrl(action)接受客户端提交的请求并分配到不同的DS(DOMAIN SERVICE),然后DS调用BO,BO在调用DAO来完成持久化!粗略地看看是没有太大的问题,耦合度也可以控制在一定程度,但是我有个问题出在哪里呢?我觉得BO是比较容易变动的东西,基于将变动与不变分离的原则,我希望可以设计一个这样子功能的bo。利用最简单的工厂模式,首先定义好一个interface在里面定义特定BO的所有行为,然后定义一个abstract class 里面定义BO的所有属性以及get/set方法,当然他继承前面的interface,然后再根据不同功能,根据职责分配的方式,以不同的实做类来实现不同功能(继承前面的abstract class),但是因为对DS来讲的话,我希望降低他与BO的耦合度,在DS来说我希望他只能通过interface访问(利用工厂实现)。表面看好象符合我要求了,也满足了提供内聚性降低耦合度的想法,但事实上大家看,如果我的BO 有三个功能的话那么在interface中必须定义三个行为才能通过接口统一访问,不然对DS来讲提高了耦合度(假如有多个interface的话),那么不考虑abstract class对于每个实做类来讲,并没有达到我想要的结果,为什么,因为内聚性并未提高,他得到了自己不想要的行为(例如实现新增,结果还有修改和查询也随继承得到了),这违背了我的初衷!我目前使用了一种妥协的办法,就是在实现类中对非本类功能行为的实现,全部都是直接抛出异常,但是非常遗憾,这比我理想的情况相差实在太远,因为这样子一来根本就不是一个良好的设计!我一直被这个问题困扰,不知道在坛的高人有没有什么很到的解决方案,或者大家一起来讨论一下此问题,小弟不胜感激!
neo_q

发表文章: 11
注册时间: 2006年04月10日 21:23
Re: 解耦合设计的一个困惑,请大家讨论 发表: 2006年04月11日 09:07 回复
如果我这样子做是否有设计过度的嫌疑,而且我也在思考是不是最初我的思路就错了!希望大家能多回复啊!小弟一直困惑啊!
banq

发表文章: 8929
注册时间: 2002年08月03日 17:08
Re: 解耦合设计的一个困惑,请大家讨论 发表: 2006年04月11日 21:42 回复
sorry,不是非常明白你的意思,可贴些代码或画张图看看。

不要试图在业务层使用工厂模式,因为工厂模式有一个前提约束:统一产品接口;其实这世界丰富多彩,没有那么好统一的,容易造成程序员强迫统一,进而脱离设计本意。

neo_q

发表文章: 11
注册时间: 2006年04月10日 21:23
Re: 解耦合设计的一个困惑,请大家讨论 发表: 2006年04月11日 21:43 回复
为什么一些回复不见了?
neo_q

发表文章: 11
注册时间: 2006年04月10日 21:23
Re: 解耦合设计的一个困惑,请大家讨论 发表: 2006年04月11日 21:49 回复
我前面的一个回复不知道在哪里去了,我的意思就是说希望如果我的bo多了一个功能的话,我不需要改代码,只需要在顶层BO(interface)中添加一个方法描述,然后再添加一个实做类就可以了,但是外面统一用顶层接口来调用!
banq

发表文章: 8929
注册时间: 2002年08月03日 17:08
Re: 解耦合设计的一个困惑,请大家讨论 发表: 2006年04月12日 11:55 回复
不知你抽象AbstractSalesBO有什么目的?是因为考虑BO需要变化,然后
基于将变动与不变分离的原则进行分离,考虑思维正确,实现方式有些问题,其实如果比较熟悉GoF设计模式,我们已经知道一个很好的解决方式:桥模式。

目前我们都是采取Domain Model/Domain Service方式来实现桥模式,Service中的一些操作行为和Model中的set/get属性分离,后者可能等同于你的abstract class东东。

另外,DS向客户端Open展示时,最好不要通过你图中的SalesBoFFactory实现,而是使用IOC模式/Ioc容器,通过IOC,就没有Facade Factory/Manager之类的缺点。
neo_q

发表文章: 11
注册时间: 2006年04月10日 21:23
Re: 解耦合设计的一个困惑,请大家讨论 发表: 2006年04月12日 13:17 回复
banq老师你说的很对,目前我想到的也是桥模式,因为我也发现了自己设计上的缺陷正在改进中:),但是我有个疑惑在这里,我的想法是这样子的:
我定义AbstractBO的目的是为了,将set/get和属性值与具体的实现某一功能的比如insert功能等的实现类分离,每当DS中增加一个功能比如多一个查询功能,那么我就想直接再加一个实现了查询的实做类,与此AbstractBO组合起来达到自己的目的,而不需要修改现存的某个类,以后如果是多了某个属性那么我只需要修改AbstractBO,而不需要修改现在的实现类,这样子达到我的设计目的,但是我目前并没有得到一个很好的方法来实现他,所有希望banq老师能再指点我一下!谢谢
banq

发表文章: 8929
注册时间: 2002年08月03日 17:08
Re: 解耦合设计的一个困惑,请大家讨论 发表: 2006年04月12日 13:27 回复
>我定义AbstractBO的目的是为了,将set/get和属性值与具体的实现某一功能的比如insert功能等的实现类分离

据现在理解,这个AbstractBO就是Domain Model啊,下面是一个典型的Model Model:


public class Message{
private String messageId;

public void setMessageId(String messageId){
this.messageId = messageId;
}

public String getMessageId(){
return this.messageId;
}

}



不知你的AbstractBO到底是不是这样,你可以举个例子,将AbstractBO其中字段show出来看看。
neo_q

发表文章: 11
注册时间: 2006年04月10日 21:23
Re: 解耦合设计的一个困惑,请大家讨论 发表: 2006年04月12日 19:50 回复
正是如此,但是我并不认为他是domain modle ,他的作用是负责在domain与dao层之间传输(或者可能会附加一点与dao层有关的方法,但是我这里没有加),所有我在这里定义一个AbstractBO,因为BO将会与DAO打交道,如果每次变更都要变更BO类,岂不是很麻烦,所以我就想到了这个法子,但是可能有些问题,因为接下来的步骤我自己都觉得很乱!接下来我是这么想的,这个BO在被DS层调用的时候,我只给他一个统一的BOInterface,而且这个接口中定义了DS层所需要的全部方法,但是这些方法我不想利用一个类来实现,这样子,那个实现类的内聚性太低,而且一但有所变化,可能会牵连很大,所有我想是每个可被DS层调用的方法就用一个类来实现,这样子有多少个功能就有多少个实现类,但是他们都只有一个统一的接口来被调用,同时这些实现类也extends 我的AbstractBO如果domain modle 有任何变化我也不需要去修改每个实现类,只需要修改这个AbstractBO 就可以了,但是我在使用adpter或者bridge的时候怎么都觉得不好,所以脑子比较乱了,希望BANQ老师能指点一二,谢谢你耐心的回复!
neo_q

发表文章: 11
注册时间: 2006年04月10日 21:23
Re: 解耦合设计的一个困惑,请大家讨论 发表: 2006年04月12日 19:52 回复
因为DS需要的不只一个方法(比如insert,update),所以用IOC也比较不可能,我也不想定义一大堆的interface啊
banq

发表文章: 8929
注册时间: 2002年08月03日 17:08
Re: 解耦合设计的一个困惑,请大家讨论 发表: 2006年04月13日 10:02 回复
>但是我并不认为他是domain modle ,他的作用是负责在domain与dao层之间传输,所有我在这里定义一个AbstractBO

你的根子问题就出在这里,这是一个Domain Model,作为你个人来说,你可能缺乏业务建模相关经验,持久层是Model的持久。

在目前理论界存在一个鸿沟,各个流派众多,尤其在Model统一上没有一致认识。

Model是业务Model,是从业务需求分析中得来的,你可参考前段时间本站首页关于四色图等业务建模方法。

Business Object(BO)是以前的概念,表示业务对象,实际和Domain Model是一致的,都是表达业务模型的,而现在Ruby on Rails/JF等域驱动框架如此流行的情况下,Domain Model已经占据Java系统的主流,你可以打开Spring/JF等很多开源软件(最近版本),他们都放弃了BO而使用Domain Model来表达业务对象。

BO大概是EJB刚刚诞生时,在J2EE模式中定义,其实,SUN的J2EE核心模式已经有很多已经不用或被相似概念替代,例如VO/DTO等。

将Domain Model作为DTO传入持久层持久,这是一个简捷直接方式,如果你专门做一个DTO,将增加系统的复杂性,就象你现在碰到这样的问题一样,焦头烂额,而且业务对象是随着业务变化经常修改,一旦修改,你还要更改DTO等各个层,问题就大了,J2EE多层结构带来了异常复杂,这在本站以前专门讨论过了。

看下图,左边就是各种DTO以后,导致系统混乱,难于维护,而右图采取以Model为主要线索,穿越各层,这样清晰便于维护:



Spring 2.0框架中,已经提供Model的CRUD等DAO操作直接在Model中实现,也就是说在业务对象中,不但是set/get,而其有自己的持久化,从这里看出,夹在Model和DAO之间的DTO更加没有必要,无疑是多余,增加复杂性,DTO从某种角度说,是以前EJB实体Bean没有采取IOC模式导致的模式。


neo_q

发表文章: 11
注册时间: 2006年04月10日 21:23
Re: 解耦合设计的一个困惑,请大家讨论 发表: 2006年04月13日 19:23 回复
banq老师首先感谢你的回复,你所提到的相关文章我也是看过的,我目前只所以会这样子是因为项目的大框架是利用BO来做的,所以我必须如此来设计。而我目前要解决的也不是各层之间的传输问题,这不是我向你请教的重点,因为在项目的大框架下面我是不可能做如此大的变动。我现在的主要问题是想做一个这样子的BO(因为项目必须用BO这种框架),在DS调用BO的时候,我不需要在一个类里面实现所有的功能,我要提高内聚性,降低耦合度,就是把各个功能的实现分到不同的类,但是DS在调用的时候完全不会感觉到这种差异,他永远只能通过interface来操作,这就是我想要的面向接口编程,比如我没新增一个功能(原来只有查询我现在要多一个新增),那么我只需要在接口里面添加这个行为,然后在实现包里面添加一个相应的实现类就可以了,这样子我觉得内聚性和耦合度都会朝我的要求的方向发展,不知道我这此描述清楚没?还是在次希望banq老师能继续给我一些建议!谢谢!
neo_q

发表文章: 11
注册时间: 2006年04月10日 21:23
Re: 解耦合设计的一个困惑,请大家讨论 发表: 2006年04月15日 15:52 回复
sir banq!!where are you?help!!
zdbj2ee

发表文章: 44
注册时间: 2003年08月29日 09:14
Re: 解耦合设计的一个困惑,请大家讨论 发表: 2006年04月17日 08:59 回复
看看Spring吧,它会给你一些启迪.利有IOC实现类之间的基于接口的松藕合.
banq

发表文章: 8929
注册时间: 2002年08月03日 17:08
Re: 解耦合设计的一个困惑,请大家讨论 发表: 2006年04月23日 15:48 回复
关键还是不能将CRUD行为分开,单独变成类,什么东东可以变成对象?你的对象粒度太细,可以说是一个方法一个对象,有些过度设计了吧?
这个主题有 16 回复 / 2 页 [ 1 2 下一页 ]
???en_US.forumThreadPrev.name??? 上一主题
Go back to the topic listing   返回主题列表    返回页首  返回页首
???en_US.forumThreadNext.name??? 下一主题
热点TAG: AOP cache DDD EJB 集群 设计模式 Hibernate IOC JiveJdon OO RBAC Spring Struts
查询本论坛内 回复超过的热门帖子
快速发表回复
标题
 
粗体 斜体 下划线 插入图片 插入代码 插入url链接 插入附件
内容
 

解惑之道在J道 ,打造中国最具影响力的的企业软件社区
OpenSource JIVEJDON v3.0 Powered by JdonFramework Code © 2002-07 jdon.com

anti spam