[TSS discussion] Spring 2.0 vs. the Anemic Domain Model

Nod, 从 ajoo 的帖子里, 没看出换掉 spring 能得到什么好处

1。不用依赖aspectj，不需要预编译。
2。不用在domain object里面加特殊的annotation。
3。domain object不用知道那个用来给它注射依赖的bean的名字。

你是说这些都不是好处？那么那个blog上面和tss上的很多人对spring的这个方案提的意见你也没看见？

晕！

你根本就没看懂Craig Wall的blog。拜托仔细看看再发言。

我们说的是spring 2.0；说的是那个用annotation来帮助依赖注入的方案；说的是在annotation里面指定bean name的方法。

扯什么1.x？扯什么xml配置？说什么autowire？都是八竿子也打不着嘛。我说我前面看不明白你在说什么呢。原来你根本就没看清楚讨论的是什么。

没看过，怎么了？
我只是看到你所提到的观点，感觉没什么可以鼓舞我的罢了。所以出来打击你一下。
 

Over the past 20 years I have actually moved away from the view represented by the idea of telling domain objects to persist themselves. Fowler may say my domain objects are anemic, but they are easy to maintain and keep in synch with various forms of persistence such as databases (relational, object, etc.) and messages. I have found that letting to service or business object act as a controller between the domain object and the interface (or view) object, the DAO, is the best way to go. MVC really represents a meta pattern of object specialization where all objects are either controllers, interfaces or domain objects but never a combination. Mediators, adaptors, connectors, MVC itself and other design patterns all work in this way. I've found that it makes the objects simpler, easier to maintain and more reusable. What is being suggested here is similar to injecting Strings with formatting objects and then telling them to go format themselves. It sounds nice, except it gunks up String. Why should the author of String have to plan for formatting or any other arbitrary operation that someone may have in mind for Strings? Why should domain object authors concern themselves with a specific DAO interface? There is no DAO interface standard. People can define their own. Do I clutter my domain object with code for each possibility? Domain objects, if done correctly can be used across applications across the enterprise. Objects should know all about themselves and as little else as they can get away with.