宅男程序员给老婆的计算机课程之9：数据模型

这次来讲MVC中***的M。

Model，几乎可以说是网页应用的核心。

之前课程提到过网页应用是由数据库驱动，而在很多场景，数据库 = M ； M = 数据库。

所谓的ORM； object relational mapping。

现在新的网页开发框架，特别是MVC框架，都会提供ORM支持，避免程序员直接写SQL、操作数据库。

传统上，ASP/ php臭名昭著的sql注入问题，便是因为菜鸟程序员直接在程序中根据用户输入拼接数据库造成的；而使用ORM框架，则可以彻底避免这种问题。

ORM有两种风格，一种是 R => O；一种是 O => R 。

====== R => O ======

传统上，程序员也都是先完成数据库设计（甚至是由DBA完成），然后再考虑相应的对象生成，也就是所谓的 R =＞　O。

在这样的场景下，整个软件的框架，还是以数据库为核心，业务的设计思维是以关系型数据库的表结构为基础去考虑的，具体应用实现上，会考虑很多关系型数据库的功能特性，比方说，外键，joining等等，并且，程序员需要直接考虑“数据库设计三范式”，以及冗余字段等面向数据库的优化手段。

并且，程序员也很可能会采用数据库的一些高级特性，如视图、存储过程、甚至触发器等等以方便使用。

O的存在，仅仅是为了方便操作数据库表。

====== O => R ======

这种设计哲学则是相反，程序员做业务分析、实现架构设计的时候，并不过多考虑数据库的特性与限制；程序仅考虑自己的业务对象：编程语言中的对象。

数据库仅仅只是作为一个对象持久层来考虑：

* 程序运行的时候，对象是自动保持在内存中。

* 但在对象状态改变、程序退出的时候，将对象保存进数据库。

* 程序重新启动的时候，则从数据库中获得原先数据，并还原为内存中的对象。

在这样的场景下，数据库是一个可以被替换的存储层，它可以是关系型数据库，也可以是NoSQL，甚至是硬盘文件；所以，即便使用关系型数据库，一般也不会使用其高级功能。

设计哲学的不同直接造成了使用技术的不同。

====== 比较 ======

在ED开发圣经PEAA中，列举了下面三种方案：

1. Trascation Script

也就是直接拼接SQL啦～

2. Table Module

R => O；并且，O非常简单，直接以类似数组的方式读取表数据。

.net中ADO.net的DataTable / DataRow对象便是这种设计的典型实现。

3. Domain Model

O => R，直接设计业务领域(Domain)的对象，然后在考虑对象的持久化方案。

针对上面3中方案，Martin Fowler画了下面这张著名图解：
http://www.hamishgraham.net/page/Work-Habits.aspx/Architecture/Business-Layer

他的结论是：

使用Table Module的方式，永远比直接写SQL简单；在简单的业务场景下，Table Module也会比Domain Model简单，但Table Module的方案复杂度会随着业务复杂化而快速增长。

反之，Domain Model的复杂度跟业务复杂度相比始终保持水平增长；它虽然一开始最复杂，但随着业务复杂度超过一定程度后，它反而会成为最简单的方案。

就我自己的开发经验，基本与Fowler的描述吻合；但随着ORM技术的成熟，Domain Model，未必如他在图中画的那样，一开始就有那么高的复杂度。

关键是看程序员是否习惯于关系型数据库的实现方案，如果是，那么，切换去Domain Model，确实会比较麻烦，各种不适应。

但如果是一个没有关系型数据库经验的程序员，或者说，没有强制使用SQL思维习惯的程序员，使用Domain Model，也可以是很自然的方案。

下一课，讲继续详细说明Domain Model。

作业：

1. ED开发圣经PEAA究竟是哪本书？

2. 数据库三范式是什么？

3. 关于Domain Model，什么是充血模型？什么是贫血模型？

系列：

网站建设、网络推广公司-创新互联，是专注品牌与效果的网站制作，网络营销seo公司；服务项目有等

声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源：创新互联

猜你还喜欢下面的内容