CodeIgniter控制器之商務邏輯執行個體分析_php執行個體

本文執行個體分析了CodeIgniter控制器之商務邏輯。分享給大家供大家參考，具體如下：

前面分析了公用控制器按模組分發，方便對特定模組的控制，而具體的實作類別則是放在library中。那放在library中是否合適呢？以及控制器中更多的商務邏輯該放在哪裡？

先說下對CI中幾個檔案夾的理解

helpers、libraries: 存放一系列輔助函數、輔助類，用來輔助控制器、商務邏輯實現功能。他們中的方法應當盡量避免與CI依賴，依賴越緊越難以複用。以郵件發送為例，發送郵件時很多參數是不變的，如編碼、協議、連接埠等，我們可能會在config下進行配置這些參數，然後library封裝一個郵件發送的類，並在其中擷取CI執行個體後讀取這些參數。此時就出現了與CI執行個體的依賴，該類就只能在CI架構中使用，其他系統要用到，就只能重寫了，沒達到複用的目的。如果發送的類只是接收參數，並封裝發送方法呢？所以說，儘可能的讓helpers、libraries變的簡單，職責變得單一。

controllers： 控制器目錄。控制器主要用來接管程式，起到串連的作用。通常情況下，我們會把商務邏輯寫在action中。但隨著業務變得複雜，action代碼將越來越臃腫，難以維護。

models： 模型目錄。CI的模型的主要職責就是和資料庫打交道，擷取資料。很多時候也會把商務邏輯放在模型中，但商務邏輯與模型實際上是兩種東西了。模型只是擷取資料，商務邏輯可能是把這些資料根據業務需要進行組合，組合方式可能有很多種，放在模型中會讓模型難以維護且不利於複用。說個碰到的例子，對資料按一定條件做緩衝，擷取資料和緩衝結果兩個流程寫在同一個方法中，但同樣的資料需要做另一種形式的緩衝時發現，擷取資料的方法就沒法重用了。

third_party：第三方類庫目錄。拿到一個類庫後不要直接使用， 可以在library中進行一次封裝，讓其更適應於系統，其他人使用起來難度也會降低。

可以發現，每個檔案夾都有自己的職責，每個模組都有自己的家，都有自己的職能。那商務邏輯該怎麼辦？

既然這樣， 我們也應該給商務邏輯安個家，建立一個唯一的目錄用來存放商務邏輯，暫且命名為service。控制器主要負責接收參數並調用service，service來調用模型，各層各盡其責。

下面看看怎麼實現：

我們可以重寫MY_Load，增加service方法，直接通過

複製代碼 代碼如下:

$this->load->service('user_service');

來調用。
但商務邏輯很多都需要擷取CI執行個體，這裡可以參考模型的方法，core建立一個MY_Service,其他service均繼承該類，這樣子service裡用法就跟控制器裡一樣了。

class MY_Service{  public function __construct()  {    log_message('debug', "Service Class Initialized");  }  function __get($key)  {    $CI = & get_instance();    return $CI->$key;  }}

其實主要思路還是需要有一層用來處理商務邏輯，java中都有這一層。隨著對CI的不斷熟悉，發覺這裡需要這一層，達到解放控制器和模型的目的。和這種類似的做法還有很多，如果系統中有很多地方需要用到web service 或者說cache之類的，其實也可以按照上面的思路單獨放在一個檔案夾中處理，方便管理。

更多關於CodeIgniter相關內容感興趣的讀者可查看本站專題：《codeigniter入門教程》和《CI(CodeIgniter)架構進階教程》

希望本文所述對大家基於CodeIgniter架構的PHP程式設計有所協助。