边界类,控制类和业务接口的使用,边界类,控制类和业务接口的关系?

05-06-30 justinwang
问题概述:

思考1:见类图1(http://blog.dreambrook.com//images/blog_dreambrook_com/justin/93/r_1.gif)的情况下,每个边界类(ListForm和DetailForm)分别对应各自的控制类(ListFormController和DetailFormController)每个控制类又都实现了同一个业务接口。该业务接口中分别有A,B,C,D,E,F六个服务(方法),其中A,B,C是为边界类ListForm服务的,而B,C,D是为边界类DetailForm服务的。

思考2:见图2(http://blog.dreambrook.com//images/blog_dreambrook_com/justin/93/r_2.gif)的情况下,每个边界类(ListForm和DetailForm)也分别对应各自的控制类(ListFormController和DetailFormController),但是每个控制类分别实现了不同的业务服务接口,左边的接口中有A,B,C专门为边界类ListForm服务的方法,右边的业务接口有D,E,F专门为边界类DetailForm服务的方法。

思考3:见图3(http://blog.dreambrook.com//images/blog_dreambrook_com/justin/93/r_3.gif)的情况下,每个边界类(ListForm和DetailForm)同时对应一个控制类,该控制类实现了一个业务服务接口。该业务接口中分别有A,B,C,D,E,F六个服务(方法),其中A,B,C是为边界类ListForm服务的,而B,C,D是为边界类DetailForm服务的。

这个问题应该算是个架构设计上的问题吧,

思考1的情况是我现在的做法,但是因为两个控制类实现的是一个总的业务接口,所以每个控制类里都有多余的方法体,一直觉得这样很别扭;

思考2的情况是我的第一个想法,为了保证控制类暴露给边界类的都是有用的方法,所以将总的业务接口拆成了两个业务接口,而两个接口也都是在一个业务服务层中的类来实现的。

思考3的情况是另一个想法,两个边界类共用同一个控制类,后台实现同一个总的业务接口,这也同样给不同的边界类暴露了他们不需要的方法,只是比思考1少用了一个控制类而已。

就这个问题跟同事好一番讨论后,没有一个统一的看法,我自己觉得思考2的实现最好(但是这种方法定义了多个业务接口,这样似乎也不太好!?),其次是思考3,最后才是现在的做法思考1。

也不知道我叙述清楚没有,大家对照类图和我的描述,应该能看懂吧……

我这方面的设计经验还不是很丰富,针对这个问题,各位同仁有什么不同的看法,欢迎大家来一起来讨论讨论。

Justin

MSN:xiaoliang203@hotmail.com

banq
2005-07-03 10:23
这是一个非常好的讨论题目,可见你对OO设计是有心者。下面是我的讨论,不只理解对否?

首先,我对你提到的三个元素进行我定义的分类:

边界类其实是域模型的界面表现,是一个实体;围绕实体有一个服务类,实际是增删改查的功能类;还有一个控制类:这实际类似一种服务运行实例控制类,我们过去说的工厂类。

如果你认可我这样分类,那么答案就比较直接得出,因为这些正是目前Ioc/AOP框架流行的业务原因。

首先,我们讨论每个边界类是否是需要对应的业务服务接口?

回答是肯定的,这样设计才能达到设计的分离、解耦的目的。业务服务接口多不怕,怕的就是他们都纠缠在一个总接口里,改动起来难免互相影响。

所以你的第2个方案在三个方案中胜出。但是第2个方案还有不到位的地方。

下面是如何解决在运行时刻,如何将边界类和对应的业务服务接口联系起来,而且不用做太多的控制类。控制类实际是一个业务代理实现问题,以前是用工厂模式实现(Jive论坛);后来用Command模式(Petstore中Web对EJB调用);现在是使用Ioc实现,如果你觉得Spring复杂难学,可从我设计的简单小巧的Jdon框架应用开始,它有丰富的中文说明书,比老外的书要容易理解多。

你说的控制类如果用Jdon框架来解决,是ModelHandler实现,这个功能可以用配置解决,只要将业务接口和对应的边界类实现对应指定即可:

<model key="username"

class="com.jdon.framework.samples.jpetstore.domain.Account">

<actionForm name="accountForm"/> //指定边界类

<handler>

<service ref="accountService"> //指定某个业务接口

<getMethod name="getAccount"/>

<createMethod name="insertAccount"/> //业务接口的新增方法

<updateMethod name="updateAccount"/> //业务接口的修改方法

<deleteMethod name="deleteAccount"/>

</service>

</handler>

</model>

banq
2005-07-03 10:26
上面贴尾部的配置如下:

<class="com.jdon.framework.samples.jpetstore.domain.Account">
<actionForm name="accountForm"/> //指定边界类
<handler>
<service ref="accountService"> //指定某个业务接口
  <getMethod name="getAccount"/>
  <createMethod name="insertAccount"/> //业务接口的新增方法
  <updateMethod name="updateAccount"/> //业务接口的修改方法
  <deleteMethod name="deleteAccount"/>
</service>
</handler>
</model>
<p>

banq
2005-07-03 10:41
关于前文说的业务代理中Factory、Command以及Ioc比较文章,见这里,希望有参考作用:

http://www.jdon.com/artichect/businessproxy.htm

justinwang
2005-07-04 15:50
呵呵,谢谢Bang的回复,让我又学到了很多东西!其实这个问题是我在实际的项目(.Net)中遇到的,虽然不是使用java来实现的,但是我想设计上的思想都应该的共通的。

我也觉得将业务接口拆开比较好,那天因为这个问题跟同事讨论了半天,看法就是不能得到统一,我也不敢说我就是对的,所以就发帖来跟大家讨论了,希望有更多的人能参与进来

其它:我在Jdon注册过用户名为Justin的VIP会员,但是密码怎么也想不起来了,提示问题也忘了,麻烦Bang能不能把我的密码发到我的注册邮箱里~

嘿嘿,永远支持Jdon

yuanfu
2005-07-04 16:09
你说的是不是就是分层的问题呢?

1、可以把两个控制类的公共方法提出来做一个接口。

2、然后做一个抽象类来实现这个公共接口。

3、每个控制类的特殊方法也做一个接口并实现这个公共接口。

4、最后每个控制类实现自己的特殊方法接口并继承这个抽象类。

common interface

/ | \

controller abstract controller

interface1 controller class interface2

| / \ |

controller controller

class1 class2

优点是:

1、益于维护,对于公共方法只要维护抽象类就可以了。

2、且暴露的接口也是必须的,没有冗余。

不知道是不是这个意思?

banq
2005-07-11 12:09
yuanfu提出的是一个Adapter模式。将控制类的共用方法和特殊方法最后实现组和适配成最后的要求。是否可这么理解。

我现在想到:如果控制类还做一些流程功能,根据后面业务接口处理的结果,进行不同的页面流程控制,也就是说这里的控制类有Meidator模式在里面。

flys
2005-08-03 11:31
这种情况应该是一个控制器调用多个接口吧,每个接口的都应该有自己的实现类(不是一个实现类)。控制器调用接口方式很多,IOC/AOP应该是目前比较先进的吧,不过还要看具体情况咯!

猜你喜欢