宅男程序员给老婆的计算机课程之11:域模型

【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系列：

1. 宅男程序员给老婆的计算机课程之0：认清本质
2. 宅男程序员给老婆的计算机课程之1：认清实际
3. 宅男程序员给老婆的计算机课程之2:怎么看待牛人
4. 宅男程序员给老婆的计算机课程之3:架构比较
5. 宅男程序员给老婆的计算机课程之4:SQL vs NoSQL
6. 宅男程序员给老婆的计算机课程之5:设计模式
7. 宅男程序员给老婆的计算机课程之6:模版引擎
8. 宅男程序员给老婆的计算机课程之7：运维的重要性
9. 宅男程序员给老婆的计算机课程之8：控制器
10. 宅男程序员给老婆的计算机课程之9：数据模型
11. 宅男程序员给老婆的计算机课程之10：做，就对了！
12. 宅男程序员给老婆的计算机课程之11:域模型