贫血就贫血,咂地?

同样道理，你会认为持久化也不是一个方面，因为没有持久化，对象根本没办法。实例化。

AOP不光可以只应用在你所说的这些场景。“存款”“取款”这样的服务也都可以是Aspect。

不是。那个示例代码确实用了auto-wire，但是，并没有禁止你用manual wire呀。
这个方案的好处，在于除了容器组装那部分，所有代码都是最基本的ioc，都不依赖第三方。

但我可以做到“单点维护”

没有持久化就无法实例化？那么java.util.List算什么？只要你调用了save()，那么我就可以期待find()的时候找到它。

而如果你直接new BankAccount()，而且BankAccount的构造函数是空的，那样find()能够找到这个对象就是违反因果，违反常识的。

至于说存款，给出例子来，不要空对空。

对。代价就是不容易理解和维护的代码，绑定于某个具体容器，不容易单元测试的模块。


其实，几乎任何东西要找都可以找到“好处”的，goto的拥护者肯定能给出goto更多的好处来。ioc的反对者也肯定会说：虽然不灵活，但是我可以直接new，方便。

大家自己权衡了。

某种程度上我完全支持Partech对于AOP容器的见解，具体的根据可以看看我的上个回帖。

说的是实体对象。

对象在内存中，不管是不是find，总会调用new不管你用多少个工厂，或者通过反射，我就在new返回的时候截获。

Ivar的AOSDWithUseCase里面有详细的描述，中文版刚出，有兴趣可以参考一下。简单的说“存款”等业务，实际就是对“资金帐户”，“利息帐户”等业务对象的横切。

不想举例子就算了。不要背书名。这个存款的业务就算没提。你主张你不举证，我们就当没这个证据好了。

如图虽然不是存款，含义一样。

你认为你的那部分依赖框架的组装代码，就很简洁，很容易理解？
不需要熟悉框架？