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

原创
开发 开发工具
这个系列来自一位宅男程序员,这个系列是他写给老婆的电脑课程。以下,开始本系列的第12篇——域模型。

【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:做,就对了!
责任编辑:彭凡 来源: 51CTO
相关推荐

2012-03-27 09:43:28

宅男程序员

2012-05-21 09:04:12

宅男程序员

2012-02-01 10:19:02

宅男程序员计算机课程

2012-02-14 10:33:12

宅男程序员

2012-05-14 09:33:21

宅男程序员

2012-03-01 09:27:23

宅男程序员

2012-02-06 10:52:14

宅男程序员

2012-02-21 09:37:07

宅男程序员

2012-02-15 14:40:17

宅男程序员

2012-04-26 08:12:01

2012-03-20 09:44:40

宅男程序员

2012-02-09 10:02:41

宅男程序员

2012-03-05 09:48:03

宅男程序员

2012-02-12 13:31:36

2011-05-11 09:42:27

程序员

2022-04-11 15:59:21

计算机

2013-03-27 09:59:33

程序员编程

2009-02-13 12:20:22

程序员计算机英语

2020-11-13 15:31:31

程序员计算机考研

2012-04-09 09:42:56

点赞
收藏

51CTO技术栈公众号