※ 引述《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
一些想法 供各位參考