再炒FormBean,VO,DTO,PO....贫血与充血

太多的地方讨论过这些东西了..
自从有了OO一说开始,O就变得满天飞啊.

看看牛人们的讨论
http://www.iteye.com/topic/627?page=1
http://www.iteye.com/topic/4233?page=1
http://www.iteye.com/topic/4173
http://www.jdon.com/article/23672.html
http://www.jdon.com/jivejdon/thread/34533.html


其实大家的讨论对分层结构都比较认同.
就是在哪个层的东西就应该封闭在那个层.不应该出现跨层的情况.
但这样,层次上是很清晰了,但就多了很多的重复,复制/粘贴.(平时我也是这样做的,但多了就比较烦啊..怀疑自己是不是太教条了.)而且这个违背了消除重复,保持清洁原则.
真的是鱼与熊掌不可兼得啊.

再看看这一篇:
http://www.jdon.com/jivejdon/thread/26395.html
好似banq与robbin的间接对话

贫血与充血

http://www.iteye.com/topic/11712?page=1
http://www.iteye.com/topic/191261
http://www.iteye.com/topic/16728
http://www.iteye.com/topic/180343
这个我认为尽量做到充血.不必去过多的细化.

引用

我们该贫血照贫血！他老人家信口开河了一把，现在自己都收不了这个场

引用

切分的原则是什么呢？ Rod Johnson提出原则是“case by case”，可重用度高的，和domain object状态密切关联的放在Item中，可重用度低的，和domain object状态没有密切关联的放在ItemManager中。

这有点更接近于职责分配原则的味道.

再看看下面的图:(与大家批评的一杆子到底差不多)
左图是现在混乱的J2EE多层系统，右图使用Naked Object的后的模型

引用

实际上，不一定所有的系统都一定要使用Naked Object，而且Naked Object导致耦合性高，目前实验只适合在Swing界面端，在服务器端成功案例还没有出现。

这给我们一个启示，我们做一个J2EE系统时，一开始必须从中间层Domain Model开始，这就是域模型驱动，而不是被具体技术牵着鼻子走，各个层技术就象小孩子一样，闹腾厉害，如果你给他们每个人分一个果果（做一个数据模型），那么你整合起来时很难，所以，你必须只给他们一个Domain Model果果，以此设计为中心，再加入其他辅助对象，与Domain Model建立对象关联(通过类图实现的四种类关系)，而各个技术都是围绕类图的类各自完成自己功能。

理清这个思路，从中间组件层入手，就能顺藤摸瓜，问题迎刃而解，这也是为什么组件层（有些人说是构件）如此重要，为什么要面向组件（面向构件）编程的重要性，为什么EJB和Spring等等吵得不可开交等原因。

引用

通过这张图我们可以看到，以前方式造成J2EE开发层次之间调用混乱，修改和拓展非常不方便，而在右边的DDD开发方式下，界面(边界)对象就是域对象就是持久化的实体BO，没有多余的Contorller或Action了。原来Domain层被服务层Service layer遮挡，在右图中，则Domain层直接暴露给前台了，所以Domain没有东西被遮盖，裸露了，称为Naked(裸露) Objects