请问banq EventModel问题
[该贴被zflang于2008-01-03 01:12修改过]
[该贴被zflang于2008-01-03 01:12修改过]
这样有一个统一包装器，解耦了表现层和业务层。
那么把各层方法的参数定义成Object类型，外层直接传入Model，然后使用时在转型成具体的Model对象不也可以达到相同的效果吗？
这里新增用户是指业务操作，比如新增一个订单，围绕订单的所有操作都是业务操作，都是业务层的，不能放在表现层，如果在表现层处理，一则订单在两个层都有操作，增加系统复杂性，更重要是违反分层。
我讲讲我的设计思路，请你评点。
在我们的业务系统中，习惯的设计是，表现层和业务层以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，经过这样的设计，只要业务需求没有改变，无论表现层如何改变，也不影响业务层。
这是一个常见方式，关键问题就是业务需求一旦变化，引起修改量太大，特别是表现层修改量最大，最后程序员不是面向业务层编程，而是面向表现层编程，和OO设计目标背道而驰。
我的做法是：表现层也使用Domain Object，做了好几个案例，目前还碰到不能绕道的问题，因为JF是消灭了表现层代码，所以，使用JF做项目逼着我尽量不做表现层代码（除非确定和显示有关）。