我在百度参与的一个最重要的项目, 项目设计的第一步就是数据库设计. 是的, 因为是重构, 所以没有人觉得这样做的问题所在. 在找出业务对象之前, 在分析出实体-关系之前, 在整理出功能列表之前, ... 在所有这些之前, 我们做了两件事: 一件是非常抽象的业务无关的系统(程序)的层次划分, 另一件是过于细枝末节的数据库表设计.
再加上我们使用了一种所谓的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! 但我们要开发的系统是个人博客系统吗? 是只有一两个表的增删改查的程序吗? 我们要开发的系统, 是在特定的时机, 在特定的页面, 当用户进行特定的操作后, 用特定的方式, 修改特定的字段.
这些框架都只是代码级别, 离业务还有十万八千里呢. 只要把业务抽象出来了, 用最流行的那几个框架中的任意一个都不会错.
不重视业务分析和理解, 却对同质化的代码框架纠缠不清, 简直和初学者没什么两样.
Loading ...
就算你添加了module层.用moudule去处理了一些逻辑.
没想过controller层的代码是不是很美观呢?
我曾经做过一个TX的项目 ,用codeigniter做的.没有像你说的自动生成的所谓的数据访问层,数据访问与逻辑都封装到了module里.然后有control层,还有view层(用smarty实现.).最后开发完成后,我发现,某些控制器代码居然超过了1000行….是在难看啊.
如果不用所谓的mvc,只有用page来做控制器.不同的页面就是不同的功能分层,这样是不是会好看些呢?
个人见解.. Reply
至于理论和学术的追求，你的看法我都认同，个人觉得实际生产要和理想状态分别对待才是 Reply