yimlin

《domain model的延伸讨论》 http://www.javaeye.com/topic/57075
robbin试图用两个例子来支撑其观点似乎太过牵强！

1. ruby的代码中是domain model直接包含了操作集合的代码，java的理念则不是如此。用来比较优劣是否妥当暂且不说，首要的问题在于：domain model理念是哪个？是允许一个对象包含自己的集合操作还是不可以？
我以为目前并没有定论。
退一万步说，就算是允许，那么java可以参照的同级别的语言是有些ADO.NET的C#（C#是可以和ruby在ActiveRecord可比的），java想做不难！
再次，允许是一回事，好不好又是另一回事。

回到正题，既然是比较就要标准统一，表面上看都是同一个题目，其实背后的理念是不一样（由此引发的种种设计实现上的变化，robbin就得出了ruby可以做更多的逻辑，因而……），
然而我以为这样的比较是支持不了robbin的观点的。

2. robbin说：“但是Java如果不使用IoC方式注入，而是直接调用依赖类的静态方法，行为就被限定死了，复杂的类依赖关系的创建和织入就是一个很麻烦的问题，这也是Java引入IoC的主要原因。”
为什么不可以直接调用依赖类的静态方法，我可以不用IoC而用AspectJ。可以看看我之前写的blog
http://www.blogjava.net/AndersLin/archive/2007/02/09/95666.html
或者
http://yimlin.javaeye.com/blog/53545
看上去有点抬杠，其实不是，看官们请冷静思考一下这个问题（又或各位不以为然，没有关系）。

因此robbin说：“对于Java来说，更加适合采用贫血的模型，Java比较适合于把一个复杂的业务逻辑分离到n个小对象中去，每个小对象描述单一的职责，n个对象互相协作来表达一个复杂的业务逻辑，这n个对象之间的依赖和协作需要通过外部的容器例如IoC来显式的管理。但对于每个具体的对象来说，他们毫无疑问是贫血的。”
从robbin写的这样java来看，似乎确实如此。然而java的程序的设计是否就此一种。
如果用AspectJ来重写代码，是否还需要那么多接口，那么类？同样加上annotation的应用，又可以省去xml文件
有关于dao的设计可以这样处理：
public class User{ public static UserFinder finder; ...... }
public interface UserFinder{ public List doQuery(...); ...... }
public class UserService{ public void FindByDept(...){ List list = User.finder.doQuery(....); .... } }
这里我选择保留了接口，实际的情况则是未必，各自选择。

3. Java在AspectJ的支持下，可以对domain model的各个方面的逻辑进行切割，就像C#的partial class那样，一个应用就是
http://yimlin.javaeye.com/blog/54060
我以为是可以解决robbin所认为的一个”充血模型的坏处“：对象高度自洽的结果是不利于大规模团队分工协作。一个编程个体至少要完成一个完整业务逻辑的功能。对于单个完整业务逻辑，无法再细分下去了。

4.如果robbin的观点是：ruby和java在实践domain model理念中，因为ruby的语言特性及其设计理念比java的有自己的优势，那我认为没有什么问题。而现有观点太过草率和武断了。


BTW：感谢newman对小弟《小议领域模型》一文的认可。