2010-04-20

我们丢失了Model层

Views: 30362 | 18 Comments

我在百度参与的一个最重要的项目, 项目设计的第一步就是数据库设计. 是的, 因为是重构, 所以没有人觉得这样做的问题所在. 在找出业务对象之前, 在分析出实体-关系之前, 在整理出功能列表之前, ... 在所有这些之前, 我们做了两件事: 一件是非常抽象的业务无关的系统(程序)的层次划分, 另一件是过于细枝末节的数据库表设计.

再加上我们使用了一种所谓的ActiveRecord的东西, 于是, 虽然大部分功能都已实现, 系统正常上线运行, 又过了一段时间, 我们突然意识到, 我们自认为掌握了MVC, 我们自认为理解了Web系统开发, 但是, 我们丢失了Model层!

我们所谓的Model, 其实就是数据库对和PHP对象的映射. 所有业务逻辑, 事务, 都放在Controller里.

造成这个结果, 我认为有几个重要的因素:

1. 缺少业务分析

在我们开始进行这个项目, 其实我们是在做一个从来没有人做过的系统. 并不是这个系统多么的先进, 而是我们面对的业务是独一无二的, 即使我们愿意花一百万, 也没有一个现成的软件可以满足我们的需求.

我们有的, 是一个2002年时留下的旧系统. 这个系统最初的目的, 其实就是几个数据库表加上一点PHP代码, 方面日常操作.

这就表示, 我们在做一个没有明确需求的系统, 而是要做一个满足未来随时提出新需求的系统, 这样的难度可想而知.

2. 缺少总体设计

正因为需求不明确, 所以, 根本无法进行总体设计.

3. 过早进行数据库设计

这是一个重要的硬伤, 在我们没有抽象出任何业务对象之前, 我们就根据旧系统的理解, 画出了一个包含几十个表的图形. 而且字段都没有确定, 都是后期不断增加的.

4. 开发框架误导了MVC概念

我们使用了一个较流行的PHP开发框架, 该框架借鉴了ROR的ActiveRecord(AR)概念, 并且有自己的MVC理解. 它把AR当做Model, 并推荐放在一个名为models的目录下面. 于是, 我们在自动生成表对应的AR之后, 便望文生义想当然地认为已经拥有了Model层. 其实, AR只不过是DAO(数据访问层), 并不是Model层.

最后, 我们的业务几乎全放在了Controller里: DB事务, DB查询, 将AR转成POPO(Plain Old PHP Object)...

我同意这种看法: keeping controllers as skinny as possible.

5. 开发框架是代码框架, 不是业务框架!

很多人没有正确地理解代码框架, 以为选了一个开发框架就完事了. 于是, 在 ZendFramewok, Yii, Symfony, CodeIgniter... 等等框架上扫来扫去. 这个很好, 那一个也很不错, 特别是每一个都能快速的开发出一个Blog系统. 对! 全是Blog系统的Demo! 但我们要开发的系统是个人博客系统吗? 是只有一两个表的增删改查的程序吗? 我们要开发的系统, 是在特定的时机, 在特定的页面, 当用户进行特定的操作后, 用特定的方式, 修改特定的字段.

这些框架都只是代码级别, 离业务还有十万八千里呢. 只要把业务抽象出来了, 用最流行的那几个框架中的任意一个都不会错.

不重视业务分析和理解, 却对同质化的代码框架纠缠不清, 简直和初学者没什么两样.

Related posts:

  1. C#封装log4net
  2. 高性能并发Web服务器实现核心内幕
  3. 关系数据库应用设计基础
  4. 基于列的数据库
  5. 开发跨浏览器JavaScript—《Ajax基础教程》笔记
Posted by ideawu at 2010-04-20 10:11:43 Tags:

18 Responses to "我们丢失了Model层"

  • 回复老王: 这里并不是说所有的开发框架都误导大众, 我们使用的Yii框架也没有推荐Fat Controller, 但是, 它推荐把AR类放在一个名为models目录下, 是不是一种误导呢? Reply
  • 没有银弹框架,针对你的问题选择好合适的框架是很关键的,要不然就会出现你拿了把剪刀去收割稻子,最后却说剪刀耽误了你。 Reply
  • Web开发框架并没有误导大众,多半是使用者自己的问题,比如CakePHP社区里的口头禅:Rich Model is Better.用户拿着MVC框架,非要自己写出一个Fat Controller来,用啥框架都没办法,再说ActiveRecord,这模式的使用是有前提的,就是你的业务模型和数据库模型及其类似,此时设计数据库基本等同于设计领域对象,SQL也就变相的成为DSL,当然,如果你的业务模型复杂,ActiveRecord自然是不合适的,此时DDD是唯一的出路,但话说回来,Web开发我很少看到非DDD不可的项目,所以框架没有错,关键在于你是否使用了合理的框架去做合理的事情。 Reply
  • 回复黑野兽: 其实你犯了文中我说到的Controller层功能太多的失误, Controller和套套一样, 应该越薄越好. 我们不仅要用MVC, 而且一定要用MVC, 但又不能把MVC等同于某一代码框架, 和面向对象一样, 首先作为一种思想, 其次才看实现. Reply
  • 理想和实际是有冲突的.
    就算你添加了module层.用moudule去处理了一些逻辑.
    没想过controller层的代码是不是很美观呢?
    我曾经做过一个TX的项目 ,用codeigniter做的.没有像你说的自动生成的所谓的数据访问层,数据访问与逻辑都封装到了module里.然后有control层,还有view层(用smarty实现.).最后开发完成后,我发现,某些控制器代码居然超过了1000行….是在难看啊.
    如果不用所谓的mvc,只有用page来做控制器.不同的页面就是不同的功能分层,这样是不是会好看些呢?
    个人见解.. Reply
  • 我曾经有过和你类似的疑惑,最后我把问题确诊为:杀鸡用牛刀,其实你的博文也提到了,一切都没有问题,这就对了
    至于理论和学术的追求,你的看法我都认同,个人觉得实际生产要和理想状态分别对待才是 Reply
  • Model层不仅仅包括了领域对象, 更重要的还有对数据的操作. 即使我不类呀累的, 完全是面向过程的函数, 也能组成Model层. 当然, 无论是展开函数的参数, 还是把所有参数放到一个关联数组(或原始PHP对象)里, 我们都可以把这些参数的整体称作领域对象. Reply
  • 你想的太理想化,太复杂了,我曾经在web开发里先设计Domain Model,在映射到数据库,基本上看过PoEAA或者DDD的人都有这样的冲动期,不过在长时间的挣扎之后,我现在又回到了起点,使用PHP做最简单的Page Controller,只有array和string,多数时候这样就足够了,也可能是我接触的Web项目都太简单了。 Reply

« [1][2] » 2/2

Leave a Comment