请问banq EventModel问题

08-01-03 zflang
请问banq 在jivejdon3中的EventModel是什么设计模式?用它可以带来什么好处?

[该贴被zflang于2008-01-03 01:12修改过]

banq
2008-01-03 14:06
将表现层与业务层的参数传送对象Model打包,类似命令模式中将请求打包。

这样有一个统一包装器,解耦了表现层和业务层。

zflang
2008-01-03 15:23
>>统一包装器,解耦了表现层和业务层。
那么把各层方法的参数定义成Object类型,外层直接传入Model,然后使用时在转型成具体的Model对象不也可以达到相同的效果吗?

banq
2008-01-04 17:08
不只是表现层传给业务层Model,业务层也要返回处理结果,比如新增用户,发现用户名重复等,包括出错信息,表现层就可以直接显示出错信息。

zflang
2008-01-07 13:46
直接在业务层处理新增用户,发现用户名重复等,包括出错信息的话会不会违反分层,我感觉这些处理应该在表现层调用业务层方法,返回结果后在表现层判断,然后再显示在页面上。用EventModel应该不够灵活。

zflang
2008-02-03 20:25

banq
2008-02-05 11:01
>直接在业务层处理新增用户,发现用户名重复等,包括出错信息的话会不会违反分层
这里新增用户是指业务操作,比如新增一个订单,围绕订单的所有操作都是业务操作,都是业务层的,不能放在表现层,如果在表现层处理,一则订单在两个层都有操作,增加系统复杂性,更重要是违反分层。

johnnylzb
2008-02-21 17:56
针对这个问题,有地方需求请教Banq大哥,不是很清楚你的EventModel的实现方式。

我讲讲我的设计思路,请你评点。

在我们的业务系统中,习惯的设计是,表现层和业务层以VO(View Object)作为数据载体互相传递数据。

这样的传统做法在最近被我否定了,理由:
1.View Object有别于Domain Object,Domain Object是业务相关对象,是业务层关心的,View Object虽然大部分情况下与Domain Object是一样的,但逻辑上,它们是两种对象,因为View Object是与表现层相关的对象。
2.这种设计,会导致表现层与业务层形成循环依赖,表现层依赖于业务层的业务接口(这很正常),业务层依赖于表现层的View Object(这不合理),当表现层发生改变时,View Object需要改变,这时候这种改变就会影响到业务层了。

我作了以下改进:

1.由于表现层对业务层形成单向依赖,所以我让业务层所以的业务方法接收的参数和返回的参数都以Domain Object作为载体,即表现层与业务层之间以Domain Object作为数据载体。
2.表现层根据不同的表现需要,自己实现Domain Object > View Object的转换,比如页面A、B同时使用到Service服务,但由于表现不同,需要使用两个View Object,业务层的同一业务只提供一个接口,并返回Domain Object,A、B根据自己的需要把Domain Object转换为View Object,经过这样的设计,只要业务需求没有改变,无论表现层如何改变,也不影响业务层。

banq
2008-02-22 20:15
>A、B根据自己的需要把Domain Object转换为View Object,经过这样的设计,只要业务需求没有改变,无论表现层如何改变,也不影响业务层。

这是一个常见方式,关键问题就是业务需求一旦变化,引起修改量太大,特别是表现层修改量最大,最后程序员不是面向业务层编程,而是面向表现层编程,和OO设计目标背道而驰。

我的做法是:表现层也使用Domain Object,做了好几个案例,目前还碰到不能绕道的问题,因为JF是消灭了表现层代码,所以,使用JF做项目逼着我尽量不做表现层代码(除非确定和显示有关)。

猜你喜欢