2012-10-11 63 views
4

希望你們中的一些人能夠幫助我。Codeigniter 2中的服務層與Doctrine 2

我在使用Codeigniter 2和Doctrine 2的項目中工作,一切工作正常,但我有一些「理智」問題,我想解決。

我現在的主要問題是堅持實體。 在一個正常的MVC中,持久性應該在模型中,但現在我只有實體和存儲庫,並且我沒有所謂的「模型」,我將所有這些代碼放在控制器中,使它們變得巨大和令人恐懼: (

我讀過一些地方,最好的辦法是在控制器和實體之間有一個「服務」層,但是我還沒有找到一個在Codeigniter中這樣做的好方法,因爲硬經典MVC模式。

這樣的IM要求在如何的形式給出了一些這方面的建議。 任何你們的是有同樣的問題?

回答

0

在同一條船上一個當時一段時間以前。最後沒有使用Doctrine的ORM,但基本上你是對的 - 對於不是通過Doctrine的實體和存儲庫直接建模的東西,你需要一個「服務層」。

我這樣做的目的是在/ application /爲我的項目代碼創建名稱空間文件夾。然後我使用Doctrine Common的類加載器將該文件夾識別爲命名空間。例如/application/Acme/Authentication.php包含:

namespace Acme; 
class Authentication { 
    //Do Doctrine queries in various methods here 
} 

主義的類加載器使用SPL(spl_autoload_register或東西)內部。這意味着你可以完全使用PHP 5.3命名空間。然後,您將獲得所有有關依賴注入的有趣嘗試和磨難,以訪問此服務層中的doctrine dbal。您的控制器將直接使用這個「服務層」。就像我說的,在我的情況下,我決定不使用Doctrine的ORM - 所以我在我的「服務層」中使用CodeIgniters ActiveRecord數據庫類。而不是使用$ this-> CI = & get_instance()...我使用DI容器爲構造函數提供數據庫訪問。

舉例來說,在我的認證/登錄控制器動作我可能

function login() { 
    $user = $_POST['u']; 
    $pass = $_POST['p']; 

    $auth = new Acme\Authentication($this->db); //or use a DI container 
    $user = $auth->authenticate($user, $pass); 

    .... 
} 
+0

感謝您的回答! 我帶來了一個對我來說看起來更清潔的不同解決方案。 我現在要佈置我的解決方案。 – Cidro

1

我發現我的問題的解決方案,希望它爲一些你。

我使用笨2和學說2喬爾的費爾哈亨整合,你可以閱讀他的詳細文章「http://www.joelverhagen.com/blog/2011/05/setting-up-codeigniter-2-with-doctrine-2-the-right-way/

簡單地說,我做的是用笨的模型作爲一個服務層。 這是我能找到的最乾淨的方法,主要是因爲所有的「接線」已經由Codeigniter完成,所以我不必做任何其他事情:D。

我不得不對Joel實現的文件夾結構做一些修改,這樣我可以使用CI的模型並仍然使用他的Doctrine代碼。 因此,我將文件夾「模型」中的所有內容移動到名爲「實體」的新文件夾中(我知道它可能不是最好的名稱,但它起作用:P)。 然後我改變了所有對新文件夾的引用,並檢查了一切正常。

就是這樣,現在我有我的「服務層」工作,我的代碼更清潔。

如果您有些人需要幫助,請隨時問我。

+0

這是更清潔。但老實說 - 使用codeigniter的佈線a.k.a它是類加載器 - 真的是最糟糕的部分。一切都像單身一樣。如果你認真地使用Doctrine,那麼你可能不應該使用CI的模型。 – MikeMurko

+0

我找不到任何不使用單一服務層的原因,對我來說,它似乎是正確的方法。你能給我一些建議嗎?謝謝! – Cidro

+0

這不是一個單獨的東西,而是一個由CI實例化的類(並且很難再次實例化)。您可能適合服務層(不是這方面的專家) - 但我認爲當涉及您的實際業務邏輯(即服務層)時,「獨立於框架」是一個很好的目標。因此,不要讓CI爲您完成工作 - 只需使用名稱空間,良好的文件夾結構和spl自動加載。這樣,你唯一的聯繫是PHP - 這是一個體面的主播:) – MikeMurko