本文實例分析了CodeIgniter控制器之業(yè)務(wù)邏輯。分享給大家供大家參考，具體如下：

前面分析了公用控制器按模塊分發(fā)，方便對特定模塊的控制，而具體的實現(xiàn)類則是放在library中。那放在library中是否合適呢？以及控制器中更多的業(yè)務(wù)邏輯該放在哪里？

先說下對CI中幾個文件夾的理解

helpers、libraries: 存放一系列輔助函數(shù)、輔助類，用來輔助控制器、業(yè)務(wù)邏輯實現(xiàn)功能。他們中的方法應(yīng)當(dāng)盡量避免與CI依賴，依賴越緊越難以復(fù)用。以郵件發(fā)送為例，發(fā)送郵件時很多參數(shù)是不變的，如編碼、協(xié)議、端口等，我們可能會在config下進行配置這些參數(shù)，然后library封裝一個郵件發(fā)送的類，并在其中獲取CI實例后讀取這些參數(shù)。此時就出現(xiàn)了與CI實例的依賴，該類就只能在CI框架中使用，其他系統(tǒng)要用到，就只能重寫了，沒達到復(fù)用的目的。如果發(fā)送的類只是接收參數(shù)，并封裝發(fā)送方法呢？所以說，盡可能的讓helpers、libraries變的簡單，職責(zé)變得單一。

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

models： 模型目錄。CI的模型的主要職責(zé)就是和數(shù)據(jù)庫打交道，獲取數(shù)據(jù)。很多時候也會把業(yè)務(wù)邏輯放在模型中，但業(yè)務(wù)邏輯與模型實際上是兩種東西了。模型只是獲取數(shù)據(jù)，業(yè)務(wù)邏輯可能是把這些數(shù)據(jù)根據(jù)業(yè)務(wù)需要進行組合，組合方式可能有很多種，放在模型中會讓模型難以維護且不利于復(fù)用。說個碰到的例子，對數(shù)據(jù)按一定條件做緩存，獲取數(shù)據(jù)和緩存結(jié)果兩個流程寫在同一個方法中，但同樣的數(shù)據(jù)需要做另一種形式的緩存時發(fā)現(xiàn)，獲取數(shù)據(jù)的方法就沒法重用了。

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

可以發(fā)現(xiàn)，每個文件夾都有自己的職責(zé)，每個模塊都有自己的家，都有自己的職能。那業(yè)務(wù)邏輯該怎么辦？

既然這樣， 我們也應(yīng)該給業(yè)務(wù)邏輯安個家，建立一個唯一的目錄用來存放業(yè)務(wù)邏輯，暫且命名為service。控制器主要負責(zé)接收參數(shù)并調(diào)用service，service來調(diào)用模型，各層各盡其責(zé)。

下面看看怎么實現(xiàn)：

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

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

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

更多關(guān)于CodeIgniter相關(guān)內(nèi)容感興趣的讀者可查看本站專題：《codeigniter入門教程》和《CI(CodeIgniter)框架進階教程》

希望本文所述對大家基于CodeIgniter框架的PHP程序設(shè)計有所幫助。