隔离的领域层1. 目的??? 将业务层的方法调用，变成非显式调用，有利于界面的自动化测试。2. 动机??? 在编写客
隔离的领域层
1. 目的
??? 将业务层的方法调用，变成非显式调用，有利于界面的自动化测试。
2. 动机
??? 在编写客户端代码的时候，很多Action 都是直接调用业务层方法（或者通过Presenter 负责调用），这样就会使界面的代码直接依赖业务层代码，在进行单元测试的时候会为业务层接口打很多的桩，工作量较大。而且界面的单元测试，主要是测试界面的布局、界面的逻辑和用户响应等，在单元测试阶段很少会涉及业务的逻辑。
3. 参与者
??? 1, Presentation： 主要负责界面的展现和用户操作的接受。
??? 2. Presenter： 主要负责用户的界面操作，转发用户的业务操作。
??? 3. Domain Binder： 主要负责连接表现层和领域逻辑层。
??? 4. Domain Accessor： 主要负责领域逻辑层的访问。
??? 5. Domain Logic： 主要负责处理业务逻辑。
4. 协作
??? 
说明：???
??? 1.图中的虚线为非显式调用；
??? 2.图中的实线为直接方法调用；
5. 实现
??? 实现流程图如下：
?
??? 由于只能加3个附件，所以其它流程图不能够加进来，具体可能参见源代码吗？
5. 结果
??? 表现层不直接依赖领域层，用户在进行业务操作时，Presenter 会将业务操作封装成一个Domain Event 发到Domain Accessor。 Domain Event 封装了操作的类型和参数。当系统需要多客户端同步时，Domain Accessor 会接收到领域层发来的事件，然后再将该事件转换成Domain Event 发出去，表现层会收到事件然后作相应的处理。
6. 特点
??? 优点：该模式有利于界面的单元测试或自动化测试，也使开发界面的人不关心业务逻辑，开发业务逻辑的人不关心界面，有利于合理的分工；
??? 缺点：用户操作被抽象成一个Domain Event，会使结构变的复杂，很难被理解。
7. 感谢
??? 感谢shaucle和BirdGu，他们提供了很多建设性的意见。
public void saveOrUpdate(String entityName, Object obj) throws HibernateException {fireSaveOrUpdate( new SaveOrUpdateEvent(entityName, obj, this) );}
这里的entityName一般用不上，也就是说其Event里包装的主要是Object和this,
如一般的save(Object)会调用
public void saveOrUpdate(Object object) throws HibernateException {
saveOrUpdate(null, object);
} 14 楼 wangyonghe 2006-12-25 我能理解你的意思，它是通过Event 的类型来区别具体的操作。
但是业务领域的操作是很难被抽象成各个不同的Event，所以必须使用字符来标识。
另外，它的fireSaveOrUpdate 方法也没有返回值，我不知道返回值在Hibernate 中是如何解决的。
例如：在添加对象时，我需要返回被添加的这个对象，它的fire 方法是如何实现的。 15 楼 BirdGu 2006-12-25 以前做网管软件的时候用过这样的模式，当时的客户端是用Swing的Rich client，用这种模式的目的是多客户端的数据同步。
在Web应用中这么做值得吗？ 16 楼 shaucle 2006-12-25 它就是在event上作文章．
saveEventListener[i].onSaveOrUpdate(event);
return event.getResultId();//这就是save返回的对象
所以俺说没返回值不一定不好测试，你可以通过判断某些对象（如event)的值来达到相同目的．
17 楼 wangyonghe 2006-12-25 BirdGu:
当然，我现在也是在Swing 中进行试验。 18 楼 wangyonghe 2006-12-25 我看了一下Hibernate 的实现，再研究一下...... 19 楼 wangyonghe 2006-12-25 BirdGu: 可有联系方式，可以留下吗？ 20 楼 BirdGu 2006-12-25 如果是为了表现层和业务逻辑层的解耦，那么只要做到Code to interface就够了。做表现层的单元测试时，用Mock代替业务逻辑层也不麻烦啊。
如果是为了在多客户端之间做数据同步，那么就考虑Observer和Command模式。
把业务操作抽象成Event可能不太直观，抽象成Command比较容易理解。 21 楼 shaucle 2006-12-25 //把业务操作抽象成Event可能不太直观，抽象成Command比较容易理解
Event和Command本质上是相似的，都是发一个Event(Action)出去,完成一系列的事情．反正对于前台就是这么个表象．
俺有次做个类似的项目(不同cms系统的文件导入问题），名字不知道用Command还是用stategy,最后干脆就用action，看着还蛮舒服．呵呵． 22 楼 wangyonghe 2006-12-25 我认为用Command 不是很合适，因为DomainEvent 不仅仅是从UI 层发向Domain 层，Domain 层也可以发送其它客户端产生的Domain 事件。
如果使用Command，好像只是从UI 层发向Domain 层的命令，不够全面。
大家还有其它意见吗？ 23 楼 BirdGu 2006-12-25 wangyonghe 写道我认为用Command 不是很合适，因为DomainEvent 不仅仅是从UI 层发向Domain 层，Domain 层也可以发送其它客户端产生的Domain 事件。
如果使用Command，好像只是从UI 层发向Domain 层的命令，不够全面。
大家还有其它意见吗？
我以前就是这样做的，UI把Command给Server，Server再把Command转给其他客户，只是Command在不同的地方有不同的执行逻辑。不同的接收者接到同一个Command作出不同的反应，这也很自然。
另外，如果UI给Server的数据和Server给其他客户端的数据有很大不同的话，那么也可以考虑UI给Server Command, Server再给其它客户端Event，Command和Event可以是完全不同的对象。当然，这个要视应用的具体情况来定。 24 楼 BirdGu 2006-12-25 shaucle 写道//把业务操作抽象成Event可能不太直观，抽象成Command比较容易理解
Event和Command本质上是相似的，都是发一个Event(Action)出去,完成一系列的事情．反正对于前台就是这么个表象．
俺有次做个类似的项目(不同cms系统的文件导入问题），名字不知道用Command还是用stategy,最后干脆就用action，看着还蛮舒服．呵呵．
合理的隐喻对于理解系统架构，有时还是很重要的。 25 楼 wangyonghe 2006-12-26 如果UI层给Domain层的是Commnad，而Domain 层给UI 层的是Event，那么我的DomainBinder 就没有什么意义了。它们肯定是一种类型。
Command 代表着主动发起的含义，Domain 层发给UI层时使用Command 肯定不合适。UI 层发给Domain 层使用Commnad 还可以接受，我再想想 26 楼 wangyonghe 2006-12-26 如果UI层给Domain层的是Commnad，而Domain 层给UI 层的是Event，那么我的DomainBinder 就没有什么意义了。它们肯定是一种类型。
Command 代表着主动发起的含义，Domain 层发给UI层时使用Command 肯定不合适。UI 层发给Domain 层使用Commnad 还可以接受，我再想想 27 楼 lane_cn 2006-12-26 软件设计是一件很自然的事情，大部分情况都可以用常识来解决，不要搞得太别扭。
要说模式，软件所有的模式都可以归结到一个模式上：层次模式。
老老实实的把业务层写出来，把业务对象原原本本的造出来，比一大堆花哨的模式有效多了。
软件的价值在于实现业务流程的自动化，需求的变更也都是从业务层开始的。业务的复杂度是软件必然无法逃避的。 28 楼 partech 2006-12-26 看了半天没看明白。
正如BirdGu所说，在service接口后面提供mock，不就隔离了领域层了么？ 29 楼 wangyonghe 2006-12-26 如果使用Mock，那就不应该称为隔离了。
我的目的是UI 层和Domain 层没有直接的方法调用。 30 楼 lane_cn 2006-12-26 wangyonghe 写道我的目的是UI 层和Domain 层没有直接的方法调用。
如果你做到了这一点，你的系统将很难开发，也很难维护。总之你是在找麻烦。
如果你希望做到Domain层对上不依赖UI，对下不依赖数据层，这是十分有好处的，也是比较符合实际的。
31 楼 partech 2006-12-26 wangyonghe 写道如果使用Mock，那就不应该称为隔离了。
我的目的是UI 层和Domain 层没有直接的方法调用。
嗯，不知道你的这种选择是基于什么考虑，如果是中小型应用，我看不出这样做有什么好处，UI层依赖Domain层再自然不过了。
如果是较复杂的中大型应用，在中间添加DTO不失为一个方法，因为这样的应用UI需要的数据和Domain层通常没有那么简单的一一映射，这种Domain对象到UI平面数据的转化会大大的简化UI的操作，同时也使UI相对独立于Domain层，反之亦然。 32 楼 wangyonghe 2006-12-27 我的目的有三方面：
1) 在做UI 单元测试的时候，不需要为Domain 写Mock。
2) 多客户端的数据同步，协作图中的Domain Binder 就是起这个作用，UI 层操作的对象可以发给Domain 层，Domain 层的操作的对象可以发给UI 层，这样就不需要每个模式块自己写同步的代码了。
3) 使客户端代码和业务层代码完全分开，这样也有利于项目组内进行分工。
