在CodeIgniter應用程序中實現服務層的正確方式

Question

以下是在CodeIgniter應用程序中可以實現服務層的兩種方式。

第一方法

1.send request to the controller 
2.calling service layer methods from controller 
3.return processed result data set(D1) from service layer to controller 
4.then according to that data set controller demand data from model 
5.model return data set(D2) to the controller 
6.then controller send second data set(D2) to view. 

---

第二方法

1.send request to the controller 
2.calling service layer methods from controller 
3.service layer demand data from model 
4.model send requested data set(d1) to the service layer 
5.after some processing return generated data(d2) to controller from service layer 
6.then controller send data set(d2) to view. 

---

在CodeIgniter中實現服務層的正確方法是什麼？除了這兩種方法外，還有其他什麼好方法嗎？

，如果你可以在代碼中提供了一個例子將是巨大的

Answer 1

請注意，這不一定是這樣做的正確的方式，但我會解釋如何像一個框架，通常可能做到這一點，那麼你就可以瞭解其他的方法和決定最好的一個你的用例。因此，我不認爲這個答案是正確的，但是我希望它至少能讓人知道事情是如何完成的，然後才能真正知道他們正在談論的事情，然後發聲（也對那些人 - 請隨時編輯/ downvote這個答案：D）。最後，這也與CodeIgniter無關，但與框架無關。你的問題不僅應該被框架爲框架不可知論的，而且也是語言不可知的。

所以我要在這裏提供意見，這是一個事實，即所有現代的框架，特別是在PHP，不做MVC。爲什麼這很重要？因爲我們都需要講同一種語言，並且'mvc'在PHP中不存在。這是事實。接受這一點，然後我們可以繼續討論框架使用的概念的混雜性; CodeIgnitor是'MVC'混蛋的一個特別好例子;此後被稱爲「mvc」，並帶有引號。

正側是，像Symfony的框架，例如，提供一種至少包含某種形式的跨應用程序一致的初始自以爲是架構，並且它是這樣的：

1. 一個標準的HTTP請求進入並擊中前端控制器，通常爲app.php或app_dev.php，具體取決於您是否處於開發或生產階段;一個涉及很多需要在每次更改時運行的緩存，另一個則不需要 - 這對於開發非常適用。

2. 路由器將當前url與控制器類和該類中的'action'（方法）進行匹配。

3. 該框架的依賴注入部分計算出從控制器轉發到模型層和返回的所有對象所需的對象，並且實例化或準備在需要時實例化它們。

4. 控制器被實例化爲任何所需的依賴關係，並執行相關的方法。這通常是你開始開發你的代碼到你的框架的地方。

5. 這是您決定您的架構的地方，但是，從開發人員角度和業務角度（爲了將來維護的較低成本）最重要的是一致性。

6. 我個人更喜歡確保我的代碼與框架分離。我將從請求中取出的標量傳遞給應用層服務，該服務使用來自模型層的對象（通過DI傳入）來使用域對象。這裏的要點是域對象並不直接傳遞給控制器​​，而是通過應用層媒介進行代理，所以你理論上可以替換圍繞這個的整個框架，而你仍然需要做的就是將這些標量傳遞給這個層在它們到達模型層之前，它們仍然可以工作（想想CLI調用，不再有更多的控制器）。

7. 應用級服務使用任何所需的Repositories，Services等（然後將這些標量放進去，記得分離？），其執行業務邏輯，（通常這些都是在您的設計模式開始發揮作用了一天），然後將該數據返回給應用程序級別的服務。

8. 該服務然後將數據返回到控制器，並猜測什麼？這是框架往往搞砸了！因爲在今天的框架中沒有「視圖」的概念。只有一個模板，你將這些數據傳遞給一個模板，這就是它。所以在你的圖表中，絕對沒有視圖的概念，因爲這不是事情的方式。說實話，我仍然在使用模板，因爲它們是最快捷的做事方式，但是直到現代框架將它們合攏在一起並真正開始使用視圖時，我們運氣不佳，並且在面對時必須保持堅定有些人（如Laravel）將自己稱爲「mvc」框架。

注，法比安斯基Potencier明確規定，Symfony的不是一個MVC框架 - 至少他知道他在說什麼有。再次，這是而不是純粹主義者，重要的是我們都講同樣的，事實上正確的語言在計算。

所以，因爲你喜歡的圖了這麼多，下面是一些可能與今天的框架做...

這對於那些擁有對每一個Review和Criteria概念的應用Review。甚至不要讓我開始使用Symfony的形式，它們如此耦合到他們不是任何架構的嚴重部分。

您需要多少個保溫層？我們已經有了「MVC」，在DDD中我們有「應用程序」，「域」和「基礎架構」分離的概念，所以先讓這兩個人一起工作，然後是這個「服務層」？你真的需要另一層，還是上面足夠？事情要考慮...

看，你不與框架/ HTTP請求卡住獲取應用程序會爲這種分離的結果會。

查看上圖中的「服務」？它們與控制器分開，所以你可以從任何地方拋出標量，應用程序仍然可以工作。 我認爲這會給你你需要的分離。以正確的方式做事，學會如何去做，然後學習如何控制自己，並且在業務和需求方面務實，但是框架需要對他們的東西進行分類 - 而且你肯定會習慣用CodeIgniter編寫可愛的代碼;）

Answer 2

您應該使用第一個。因爲在MVC Web應用程序中，控制器用於將業務邏輯從視圖中分離出來，它就像網關一樣。你需要使用控制器開始處理你的信息，從你應該調用模型或服務層的控制器或你需要的任何東西&最後你應該返回數據到這裏的任何其他來源。您的視圖或服務層不應直接訪問模型。

Answer 3

恕我直言，沒有對錯：

選項＃1 - 如果你想重新使用多個控制器/動作 業務層和基於不同的模型給它的數據要求第一個是有意義的。

選項2＃ - 然而，如果您的數據模型更復雜，第一個選項可能會有問題。如果需要根據第一個呼叫的數據再次調用模型，該怎麼辦？使用該業務邏輯的控制器違反服務層的整個目的。在這種情況下，最好去第二個。

我認爲第二個是比較常見的一個。

Answer 4

依賴注入和適配器模式將是一個很好的開始。 CodeIgniter支持既不是開箱即用的，所以你需要編寫一個包裝器或者一個鉤子。

您的視圖只能支持xml | html，因爲json需要預先呈現給.json文件，然後作爲輸出返回，但這需要通過代碼完成，只需返回該對象即可並在前端進行了修改。 PHP是一種嵌入式語言，它與（xml | html）配合使用

服務模型在將注入（依賴注入） 注入到控制器/模型中並且作爲該控制器/模型的屬性列出時效果最佳。

該服務然後綁定接口

例如Facebook的/微 他們都有一個請求和響應功能但兩者遵循類似的模式，但具有不同的端點。這裏需要

interface SocialMediaAdapter{ 
    public request(url); 
    public response(); 
} 

---

public class FaceBookProvider implements SocialMediaAdapter 
{ 
    public request(url){ 

    } 
    public response(){ 

    } 

}

public class TwitterProvider implements SocialMediaAdapter 
    { 
     public request(url){ 

     } 
     public response(){ 

     } 
    } 

---

public class SocialMediaServiceProvider{ 

    protected $provider = null; 

    public function constructor(SocialMediaAdapter $provider){ 
     $this->provider = $provider; 
    } 

    public function fetch($url){ 
     return $this->provider->request($url); 
    } 
} 

依賴注入

new MyController(new SocialMediaServiceProvider (new FacebookService))