贫血就贫血,咂地?

当我们开始分析一个问题的时候, 不要抱着那么强烈的非得遵照什么经典模式的死脑筋, 语义分析才是最重要的, 只有语义划分合理后面才会少很多麻烦, 不要再被设计模式误导了.

当然, 我并不是反对设计模式, 只是设计模式本来就是人总结出来的, 不去领会总结推动设计模式出现的动力和思路, 反而执着于已经总结出来的设计模式, 顶多是个信徒而已.

此言差矣，AOP是一项全新的寻求突破的尝试，跟死板、生搬硬套、迷信完全搭不上边，只是AOP的侵入式语义模型杀伤力实在是太大才需要审慎对待。

我不反对任何尝试解决某种问题的方法. 只是我觉得在分析一个问题的时候, 不要老是强烈的想着某个模式, 非得向这个模式靠拢, 相反, 模式是应该跟着语义分析走的. 有可能语义分析的结果跟你之前预期的模式很吻合, 也有可能会有不少的出入, 甚至可能是几种模式的部分特征的混合体.

当然, 我仍然要声明一下, 我并没有反对AOP的意思, 呵呵.

不知道你所指的侵入式的语义模型 是什么，如果是AOP的模型的话，我认为也不算拿刀往自己脖子上靠。 如果要做一个比喻的话，我倒觉得象是捉住一个新发明的飞行器，有可能掉下来摔上一跤罢了。但爬起来继续赶路不会耗费什么体力。

AOP对丰富领域模型的侵入性并不是非常严重，我认为，严格来说，算是对外在应用层（指依赖于此领域模型的应用层） 的侵入，因为你从领域模型里面任何一个类的代码来看,最多只有配置级别的侵入（Annotation 或者XML配置文件，我个人推荐使用XML配置文件) ，而没有逻辑代码上的侵入。
可以把对Service的IOC看作一个层，那么这个层面上的替换就可以使用有争议的AOP或者类似AJOO的工厂式的IOC注入。
如果实在不行，这两者之间的切换也远没有要上断头台那种恐怖。

问题是配置也不一定是和逻辑无关的，比如说需要根据顾客的等级来动态配置不同的服务，这时使用AOP就是对业务逻辑的入侵了，况且需求的变化是无法预计的，今天不依赖业务逻辑的配置说不准明天就产生了依赖。单一OO模型可以保证平滑的扩展，加上AOP风险明显就不一样了。

在目前的环境和条件下，一般首选Service Locator

如果在具体的一些小的项目中想要练习试的实施一下AOP的话，我想PM应该需要考虑这个技术风险的，至少他应该做出可以容易切换到IOC或者ServiceLocator方式的架构，很多东西动手做一些小的项目就很快可以看出其中猫腻来了。 至于真正的项目，没有小项目的铺垫，我可不敢打保票一定要上AOP。
因为我真不明白它具体带来什么风险，我只看到了一些透明的好处而已。不过这个好处对我有些勾引作用。

另外对于你提到的：
问题是配置也不一定是和逻辑无关的，比如说需要根据顾客的等级来动态配置不同的服务，这时使用AOP就是对业务逻辑的入侵了。
不知道你具体的环境，但是此时你所提到的情况似乎触及到了我对AOP封装的底线，AOP应该仅仅关注与与业务无关的横切面。  象你提到的情况，我不认为对顾客用AOP来动态注入服务是一个好的设计。相反，这个时候，我很乐意把它作为一个用户故事来做，我会把它放到一个工厂方法里做IOC，或者直接setter Service，给一个好一点的命名：bindServiceToCustomer(Customer customer) 。

确实在没有搞清楚AOP到底能带来什么的时候贸然使用似乎会带来很大的风险。
不过，目前我不认为这种所谓的“侵入”有多少实际的坏处。相反我认为它实现了更好的封装。
正好目前处于新项目启动阶段，有充足的时间能够试验。
不但要让AOP只“侵入”服务，我还会让AOP直接“侵入”RichDomainObject。
你们这样一说，看来俺还得注意检查一下，头盔和安全带是否系好，赫赫

两个星期没时间上论坛。这个帖子就沉下去了？

顶起来！


总结一下我的观点：

1。使用aspectj得到的所谓单点维护的效果用service locator完全可以得到。两相比较，service locator的坏处aspectj的方法同样有。而service locator还比aspectj直观，简单。

所以，aspectj被排除法简单地排除了。呵呵。


2。service locator和dependency injection的区别我就不多说了。DI要求你声明一个依赖，并且从外面注入一个domain工厂，不可以直接new domain object。
service locator要求你在domain object里面必须调用locator.get()，灵活性有所缺陷，单元测试能力减弱。
如何抉择，就是是否采用ioc同样的理由了。不赘述。


3。无论如何。对hyperaemia model的依赖注入是比较尴尬的。反过来想，这是不是可以算是充血模型的一个问题点呢？反正贫血模型就没这个毛病。