【51CTO独家特稿】在前面的课程中提到PEAA中只有一页半的Active Record Pattern ( http://martinfowler.com/eaaCatalog/activeRecord.html )影响了过去5年多6年的Web开发潮流。
这个潮流是由Ruby On Rails引领的。
RoR的作者DHH David Heinemeier Hansson是Hacker，他因为RoR在2005年被Google跟O'Reilly选为年度黑客。
他在设计RoR时，选用了Active Record作为RoR的M层。
Active Record非常简单，一个类对应一个表，一个对象实例对应一行数据；并且有简单的有Save / Delete以及查询等简单的函数操作。
严格的说，Active Record不是福勒所推崇的充血Domain Object模型 （ http://martinfowler.com/bliki/AnemicDomainModel.html ），Active Record对象提供的功能函数太少，只有通用的数据操作方法，而不包涵业务逻辑；但它又不像POJO （ http://martinfowler.com/bliki/POJO.html ） 那样完全的贫血。
（充血、贫血Domain Object之争，可以去iteye翻帖子）
从福勒 AnemicDomainModel 一文看，他在当年（2003）是推荐了充血Domain对象跟POJO，但过去几年在Web开发领域所流行的却是 Active Record这样两边都沾点，但却又不全是的中间妥协方案。
不搞教条主义，什么实用用什么，POJO不够，那么就加一点；充血太复杂，那么就减少一点。
从互联网的发展看，我一时间完全想不出有什么在理论上被设计得很好的模型，能够最终经历时间考验成为事实标准。
因特网的7层模型，实际用到的远不到7层；Java的EJB挂了；XML被JSON取代等等等等。
也许学院派提出的理论有他们的应用场景，只是，这样的场景，在快速发展互联网似乎很难找到例子。
互联网产品的业务相对简单，Active Record已经足够好，足够方便，因此大行其道。
另一方面，互联网产品做大后，也往往有着极大的性能要求，一个复杂的模型，是难以做性能优化的。
像Active Record，因为足够简单，Twitter在当年遇到性能问题的时候，便直接Hack掉RoR的实现，增加了 Cache-Money （ https://github.com/nkallen/cache-money ） 这么一个透明的缓存层。
如果RoR使用的是充血对象模型，对象中有复杂的业务逻辑，如何增加透明的缓存呢？
Active Record的实际上是对数据库操作做了抽象。
封装、抽象是一门艺术。
什么该封装，什么该暴露，什么彻底不可见，需要拿捏得很准确。
最容易犯的错误是过度封装，使得一些本来很简单的底层操作，到了上层变得完全不能用；或者说，很难用。
开发者需要用到hack的方式，才能去做这些简单的操作。
Active Record便是一个抽象封装得恰到好处的例子。过度设计、过度封装的数据操作层？EJB。
按照教科书对OO的定义，OO的核心特性之一是：encapsulation http://en.wikipedia.org/wiki/Encapsulation_%28object-oriented_programming%29
Private属性、方法，对象外部是完全不能访问的。
但如果遇到了需要访问的场景怎么办？！
有的人会说：“这样的场景本来就不应该出现，这是对象设计一开始没有做好造成的，错误的应该设成Public的属性设成了Private”。
ORM，采用O => R的映射的设计哲学，只考虑业务对象，完全不考虑底层数据库，数据库仅仅是一个可以被替换掉的持久层，它可以是关系型数据库、也可以是NoSQL，甚至是硬盘文件。
也就是说，Domain Object是把后端数据库给设成“Private”了，即便底层是关系型数据库，你也不可以直接去写SQL。
即便你使用的是MS SQL Server，你也不能去调用它特有的SQL特性。
Asp.Net刚出来的时候，微软曾经鼓吹过一个叫 N-Tiers 的架构：http://msdn.microsoft.com/en-us/library/ms973279.aspx / http://msdn.microsoft.com/en-us/library/bb384398.aspx 。
我曾经以为这是王道，直到我膝盖中了一箭……呃，不，直到我看了Joel Spolsky写的 The Law of Leaky Abstractions：http://www.joelonsoftware.com/articles/LeakyAbstractions.html
理想很丰满，现实很骨感。
ORM工具再怎么封装都好，底层用了数据库，就是用了数据库。
开发者必然需要了解数据库的特性，能否直接调用数据库的特性，是一个选择。
是否要彻底对上层屏蔽掉数据库的存在，也是一个选择。
N-tiers架构推荐一层又一层的封装，如果错误使用，把选择当成教条，是会有噩梦的。
========
Python是一门很有趣的语言，它支持继承，能实现OO，但是缺乏 encapsulation 的语言支持。
Python根本就没有public / private这样的关键字，然后呢？
然后可以回过头再去看：“这样的场景本来就不应该出现，这是对象设计一开始没有做好造成的，错误的应该设成Public的属性设成了Private”。
这句话，这话说得对嘛？
作业：
1. N-tiers架构的噩梦场景是？
2. 什么系统/场景需要充分使用特定数据库的特性？
51CTO系列：
