解放思想，走出传统三层架构的束缚

http://www.jdon.com/jivejdon/thread/38851      转载借鉴，学无止境苦作舟。

 

 

05年底的时候，我们项目组要开发一个ERP的系统。我们选择了jsf(ADF)+spring+hibernate的架构进行系统开发，3层分层架构进行设计开发。技术经理把表设计好，跟我们讲清楚表和表之间的关系，然后我们写model,dao,manager,form来实现。那时候我根本没有什么面对对象的设计或者面向数据库的设计的概念，感觉应用系统主要就是设计表之间的关系，数据库的一系列操作。这样浑浑噩噩过了1年多，在jdon上了解了设计模式，但是那时总觉得很难把设计模式落到实处。可能这也是面向数据库设计的结果吧，领域对象都是贫血的，没有行为，只是一个数据的容器，所以也谈不上封装变化什么的。

又继续用这个框架做了几个项目，项目组的人在无意之中倒也配合我的无知。有人画界面原型，有人直接设计出数据表，然后我就吭哧吭哧根据表建model对象，然后利用自己写的模板，快速生成dao,manger,form,jsp界面。呵呵，我估计现在有些公司也是这么做的，结果很明显的，一开始开发速度很快，随着客户的需求变化，你的manager层的逻辑代码也越来越复杂，model中也出现了一些不想看到的字段，再最后，有些manager的业务方法，都不忍心看了。

一直感觉自己徘徊在OO设计的门外，入不了门，直到最近对业务系统设计有了新的认识，以及明白了领域对象生命周期这个概念。

我现在已经明白对系统进行OO设计还是数据库设计不是jsf+spring+hibernate架构所引导的，而在于你是不是有OO的思想去引导你的设计。但是这个架构，或者说这个架构的一些流行的例子确实会给经验不深的设计者产生束缚，会让技术架构影响了对象设计，从而限制了设计者对对象设计的想象能力。用这个架构的时候，领域对象一般是贫血的，jsf页面直接绑定领域对象，然后在web的action里调用manager层进行对象的数据交互和持久化。在这样的思路下，领域对象好像只是一个临时性的数据容器，为request-response阶段业务数据的交互，持久化服务的，他没有舞台去表现他的表达业务的能力。这难道就是领域对象应该扮演的角色吗？把自己的舞台让给更像是技术对象的service来表演？没有更好的方法去表达一个系统吗？当我看到《领域对象设计》这本书的第6章领域对象的生命周期这一章时，看到banq的cargosimple中用的xxxInMem.java这样的仓储类时，我发现原来可以换个角度来理解一个业务系统的。业务系统是领域对象的活动场所，领域对象本身具有的数据和他的行为才是一个业务系统最核心的东西，而数据库是对象冬眠的一个地方（对象冬眠好象有点不恰当，因为数据库做的只是对象数据的持久化）。而orm这些框架，变通的实现了对象的冬眠，及对象的唤醒。我觉得这样去了解一个业务系统太棒了。因为领域对象有生命的，所以设计师可以决定领域对象存活多少时间。比如说，我以前的项目中，领域对象的生存周期都是在一个request,response中的，时时刻刻都被冬眠，造成的结果就是整个业务系统里，没有活动的领域对象，都是冬眠的对象，而要使用这个系统，就需要先把领域对象唤醒，然后进行业务交互。而现在看的一些例子，dddsample,或者JiveJdon，都是把领域对象放到缓存中，对象在里面不需要冬眠，是活着的，那么整个业务系统就是有生命的，或者说效率比较高的。

随着对领域对象生命周期的了解，也解开了看示例项目时产生的一些疑惑。现在看的一些示例项目，发现领域对象里往往都有同步方法，而自己以前写的项目，根本没有用到同步功能。现在分析起来，是因为我以前的项目中，领域对象都是贫血的，没方法需要同步，而且领域对象都是request-response期间的，每次被客户端唤醒（比如通过hibernate)的对象其实是不同的对象（业务上可能是同一个对象，但是机器系统里的这些对象的内存块不一样），因为是不同的内存块，所以他们的方法也就不需要同步了。而现在当领域对象有状态后，可以一直活在内存里，那么每个客户端用的领域对象都是可以是同一个（无论业务上，还是机器系统的内存块），那么领域对象的一些业务方法涉及到领域对象自身的数据变化时，就可能需要同步了。