在我當前實現的MVC設計模式中(使用PHP和CodeIgniter演示):如何處理這些頁面特定的小類,它們似乎不適合作爲CodeIgniter中的模型或庫?
假設我有一個位於「www.mysite.com/blue/page」的「頁面」,它最終由以下(大大簡化)文件:
/庫
session_lib.php
/控制器
/紅色
/白色
/藍
page.php文件
/型號
/紅色
/白色
/藍
funky_class.php
page_model.php
/視圖
/紅色
/白色
/藍色
page.php文件
下面是一個易於理解的控制器:
// FILE: /controllers/blue/page.php
// Get some paramaters from URL
$params = $this->input->get();
// Use a library to do some stuff with these params with a session
$this->load->library('session_lib');
$this->session_lib->store_in_session($params);
// Use a very page specific class to do some funky stuff with the params
$this->load->model('blue/funky_class');
$funkified_params = $this->funky_class->funkify($params);
// Pass params to a model
$this->load->model('blue/page_model');
$data['output_from_db'] = $this->page_model->get_some_output_from_db($funkified_params);
// Send to view
$this->load->view('blue/page', $data);
現在的問題...
什麼是這些「時髦」小頁的特定類的最佳方法不與數據庫交互?在這個例子中,我使用模型存儲小類,並且在某些情況下,可能會在模型類中添加其他方法來做時髦的事情。 這是一個很好的做法嗎?或者圖書館和時髦類都應該進入模型內部,以便控制器更加瘦(但是模型可能在其他地方使用,而不需要會話和funkiness)?
什麼是「時髦的東西」在做什麼?它是數學轉換嗎?計算佈局?將過去的迴應與潛在的未來回應聯繫起來 – wallyk
好吧,一個例子可能是「funky」是一個類,用於根據用於過濾數據網格(模型)的傳遞參數創建一組時髦表單輸入。 – prograhammer
另一個值得關注的問題是:有時候控制器會調用如此多的庫和模型,並在控制器本身看起來像一個模型,處理大量的業務邏輯之間傳遞東西。 – prograhammer