从责任分离的思想理解oo dp orm aop
I序
在整个古代，随着物质生产力发展水平的提高，在原始社会后期和奴隶社会形成的过程中，先后出现了三次社会大分工：第一次社会大分工是农业和畜牧业的分离，以及原始人群分化为农业部落和游牧部落；第二次社会大分工是手工业和农牧业的分离，以及专业手工业工匠的形成；第三次社会大分工是商业和物质生产领域的分离，以及特殊商人阶层的形成。在三次社会大分工的基础上造成了城市和乡村的分离，逐渐形成了物质生产和精神生产、体力劳动和脑力劳动以及体力劳动者和脑力劳动者之间的分工，即社会基本分工。
社会大分工对人类社会产生了巨大影响.责任分离就是其中重要的思想.
联系到软件行业,责任分离又是如何指导我们的发展的呢? 让我们从责任分离的思想来看看当今的技术.
对于软件行业, 从过程化语言到面向对象语言无疑是一场巨大的变革.
II面向对象和设计模式
从过程化的模型转变面向对象, 发生了什么样的变化?
一个功能的完成不再是一气呵成了,而是通过一个个对象之间进行协作,相互之间发送消息以完成一个复杂的任务.咋看之下,这个过程似乎变的复杂了,然而如同人类社会的分工,每个个体充分发挥了各自的作用,专注于自己的任务,脱离了外界的复杂联系,提高了效率, 也给我们带来了可复用的软件.
记得<
设计模式充分发挥了责任分离的思想.看看这本书对模式的分类:Creational Patterns, Structural Patterns, Behavioral Patterns,这样的分类就是基于责任分离的原则所做的,将对象的创建,组织和行为交互分开,从三个方面来谈如何使用对象.
再来看几个具体的模式,Visitor模式可以方便的为原有的对象扩展新的功能.这样就可以更好的组织对象的责任, 一些重要的与本身联系密切的责任由自己实现,而一些与本身联系不太紧密的或者将来想扩充的一些责任就可以交由其他对象来通过Visit原来的对象完成.
Bridge模式则更是将一部分责任抽出新建了一个对象,由它来完成那部分责任.为什么要这样? 因为那部分责任是多变的,完成的方法有很多种.将责任分离可以使得每个对象关注的变化少一些,也就更容易控制和管理,这和人类社会的分工思想没有太大的差异.
谈到设计模式免不了谈到一些设计的原则.单一责任原则从名字上就可以看出它和本文的联系,每个对象专注于一个责任这是最理想的状况, 最方便管理. 依赖倒置原则似乎看不出它与责任分离的联系,但是在下面的文章中你将会看到依赖倒置原则是如何为责任分离所服务的.
开源领域中最为炙热的ORM, 为联系现实的对象世界和关系型数据库搭起了一座桥梁
III ORM
在当今软件的世界里，面向对象技术一统天下，渗透到几乎所有软件设计领域、应用领域和工程领域。与此同时，在数据库领域中，虽然关系数据库占据了绝大部分的市场份额，Oracle、DB2、SQLServer、Infomix成为数据库中的霸主，但关系数据库究竟还是是数据的一种存储方式，它不属于面向对象领域。当以关系数据库为数据存储方式时，由于关系概念与面向对象概念是完全不同的两个概念，它们之间存在严重的“阻抗失谐（Impedance Mismatch）”。为了解决这个问题，面向对象技术和数据库技术自然而然开始交流和结合，应用上层的面向对象要求渗透到数据库，甚至是数据库底层，并开始影响未来数据库的发展。
现代技术的发展，使得我们不得不不停地学习。我们不仅要学习面向对象、UML、设计模式等知识，而且还需要学习Sql Server、ADO.NET、DataSet、DataReader等知识。而在实际的开发中，真正对客户有价值的是其独特的业务功能，而现在的现状是我们花费了大量的时间在编写数据访问，CRUD方法，包括后期的Bug查找，维护等也会花费相当多的时间在数据处理上。这就是说，我们在实际的开发中很多的时间都被浪费在根本不创造价值的非业务事件上了。
在使用ORM之后，我们将不需要再浪费太多的时间在ADO.NET和Sql语句上。ORM框架已经把数据库转变成了我们熟悉的对象，我们将只需要了解面向对象开发就可以实现数据库应用程序的开发。
将业务建模和数据存储的责任分开来, 可以使我们更加关注于我们需要关注的东西. 每次的开发变化在于业务模型的变化而不是数据的存储, 业务建模才使我们需要关注的东西.
责任的分离一方面使得业务开发人员减少需要编写的代码, 获得更高的开发效率, 同时将ORM交给对数据库更加在行的专业开发人员, 还能提高数据访问的性能, 速度和质量都获得了,这正是责任分离能给我们带来的最大的好处.
OOP之后的AOP又给我带来了什么新的东西
IV AOP
现在考虑一个简单的MVC应用。我们有个很简单、清晰、单一的设计需求，就是说：当model类的某个状态发生变化时，所有注册了与之相关联的view类要被（以某种方式）通知到这一变化。一般来说，在一个典型的实现中，你可能会在Model类管理状态改变的方法中看到散布各处的一大堆类似notifyObservers()的调用。Model的责任应该只是管理状态, 现在却要负责通知view, 这个责任就应该被分离,不然就不会有那么多的notifyObservers()调用, 这样不方便对程序的维护和修改(比如你要把notifyObservers()改成notify()).
这时候就是AOP就出场了, 它可以对Model状态进行一个横切,然后插入notifyObservers().它的实现就是将责任分离的思想发挥到了一个更高的境界. OOP对此没有办法,而AOP就提供了在更多的情况下实现责任分离的可能.
权限的管理, 日志的记录, 事务的管理, 这些责任都应该脱离于业务对象, AOP的最大目的就是实现此种情况下的责任分离.所带来的好处和ORM有着完全类似的效果. 目前多是依靠J2ee来帮助我们做这些事,以后可能更多的是由Spring JBoss等等来帮助我们.
AOP还有一个特性就是实现完全的依赖倒置.在目前的OOP下我们可以在某种程度下实现依赖倒置. 比如 A -> I <- B , 通过I这个接口我们实现了将A对B的依赖转为B对A的依赖. 然而在AOP下我们可以实现真正的将A -> B变为 A <- B.
如果将AOP的这一特性应用于ORM, 你能想象出什么样的结果? 我们是不是可以完全脱离数据库,就象没有数据库一样直接使用我们的业务对象, 和目前的ORM是不是又不一样了呢?