※ 引述《j87b0003 (I'm 邱老虎)》之铭言：
: 虽然CI很久没更新了…(我也离开写程式行业二~三年)
: 不过近四个月，也越来越有心得，后来就慢慢找到自己的习惯开发方式
: 我自己个人：
: 【Model】
: 负责与数据库，所以几乎会写概观的通用性
: 通常会有：
: get_list($where, $limit, $offset, $order)
: 用来分页/列表用
: get_where($where)
: 取得单一资料
: on_duplicate_batch($data)
: 资料新增与更新
: delete($where)、add($data)、update($data, $where)
: 后面的新增和更新几乎都很少用了
: 【Libs】
: 介于model和controller中间
: 把model的功能性除原本的，也做更多扩充，做更多细项
: get_list_rows($where) =>> model->get_list($where)->num_rows()
: get_by_id($id) =>> model->get_where(array('id' => $id ))
: on_duplicate($data) =>> modetl->on_duplicate_batch(array(0 => $data))
: delete_by_id($id) =>> model_delete(array('id' => $id ))
Hi
model的部份这个给各位参考 功能强大
https://github.com/jamierumbelow/codeigniter-base-model
: 【View】
: 以add、alter为例，会共用同一个view，
: 在js检查完后，直接以
: var data = {
: field : field_data
: }
View的部份 也许可以考虑找个template
这个给各位参考
https://github.com/philsturgeon/codeigniter-template
Codeigniter本身有点限制
譬如他没有良好的test支援 内建的test library太阳春
开发方法论上无法进行TDD(testing driven development)
解法还是有的 整合simpletest这个php测试工具即可
这个给各位参考
https://github.com/ericbarnes/codeigniter-simpletest
另外 Codeigniter没有内建ORM
CI_Model什么功能都没有提供
而$this->db所抓出来的资料 是直接对应到数据库的array
就算是object也只是stdClass object
方法论上 若是采用DDD(Domain Driven Development)
由于无法设计domain class
你无法写出类似这样的东西
$this->load->model('Car_model');
$car = $this->Car_Model->get($id);
// 这台车子开跑了
$car->run();
// 车子坏了 显示讯息要求修理
$car->askForFix();
在不引入Redbean之类ORM的情况下(采用Active Record pattern)
很难实行DDD方法论
若是想用Data Mapper pattern去实作DDD的话
除非引入Doctrine之类的工具 否则实作起来依然十分辛苦
可以说是Codeigniter会鼓励'反正model吐阵列资料给controller用就对了'的想法
程式码极度容易出现Fat model的现象
反正就是设法用$this->db去吐资料出来
常常会出现真的非常fat model的现象
fat model skinny controller并不是一个好现象
应该要skinny 所有东西
fat model是贫血model 糟糕design pattern的一种
http://www.martinfowler.com/bliki/AnemicDomainModel.html
在开发速度/结构漂亮的平衡之下 我所想到又快又美的方法只有..
model稍微肥一些没关系 但是请引入Service Object的观念
有些功能确实直接放进model似乎很合理 但是跟Model本身没有直接关系
只有间接关系、互动关系的功能
举例来说
假如一个电子商务网站要做发email 备份数据库 两件事
不要在Order_model（订单的model）里面实作这两件事
在library底下开一个MY_APP资料夹 里面在开一个Services资料夹
建立DatabaseManager.php与MailSender.php
里面写类似这样的东西
class MailSender{
protected $CI;
function __construct(){
$this->CI =& get_instance();
$this->CI->load->database();
}
function advertise_to_friends($data){
// do something
}
}
在需要执行这些service的controller或是model内 这样写即可
$this->load->library('MY_APP/Services/MailSender');
$this->mailsender->advertise_to_friends($data);
将一大堆service独立出来、整理在一起 可以大幅降低fat model的现象
fat model根本就是God pattern 小project就算了 中型以上请避免
也许会有人想说 library应该是放一些工具包吧 怎么会把商业逻辑放进去
我想提到一件事 就是“框架不是你的应用程式”
以我上面举的例子来说 应用程式几乎只是那个MY_APP资料夹
框架'可以'视为不过是提供使用者接口的手段而已
http://blog.firsthand.ca/2011/10/rails-is-not-your-application.html
一些想法 供各位参考