?
从表面上来看，AOP是个好东西，但是仔细看，发现不是那么美。
?
AOP的不当使用，使代码失去主线索，成为“方面”的分割。而主线索代表了一个产品代码中所围绕的主要概念。
“方面”应该是为“线索”和“流程”服务的，在AOP之前的编程范式中，流程会调用好多基础包完成自己的流程，而AOP之后，无须再调用，自动织入。
其实想想，AOP的织入和普通用的模板模式何其相似，模板模式用的好，效果也非常接近AOP了。你说“业务过程无须再考虑日志的记录，所以日志做成单独的方面比较好”，但是为什么日志不是业务过程要考虑的？什么时候记日志，记什么内容，当然且理所当然是业务要考虑要设计的，这是我的理解，和现代AOP架构部一致的地方。
作为一个设计者，你的每个业务流程，考虑参数检查否？考虑权限判断否？考虑数据库交互否？考虑记日志否？当然都应该考虑，这是完整的过程。可以由上层设计师做成模板模式，由代码实现者只做数据库交互就可以，但是设计上是有全流程的设计的。
那么，如果只对无关紧要的部分使用AOP是否可以？当然是可以的，但是既然已经无关紧要，那么用不用什么心的架构，意义和价值都不大了。
另外，之前的设计过程，某一个业务流程出现错误，只需找特定的一个或几个人负责，现在一个业务涉及到整合的若干个方面，出错了再也要找更多的人来处理，这是小事，但是很烦。
?
从另外一个角度说，你是设计师，你不能总是嫌业务复杂和繁琐，因为这是必然要面对的，逃避不是办法。
?
相关文章
