2009-09-24 68 views
4

我正在研究使用Doctrine2與我的Zend框架設置。我非常喜歡datamapper模式,主要是因爲它用我的數據庫分離了我的域模型。什麼是最好的MVC,Doctrine2,Datamapper練習?

我的問題是在我的控制器中使用Doctrine和DQL的最佳做法是什麼?

  1. 控制器使用原則 DQL/EntityManager的直接 保存/載入我的域模型?

  2. 創建於 DataMapper的模式我自己的類 保存/載入我的域模型,並 然後在 我自己的類使用Doctrine內部?

優點。對於#1當然是我不需要創建我自己的數據映射模型,但是再次用#2我可以稍後替換原理(理論上)

你會做什麼?

回答

3

關於你的抽象問題,我會說這實際上取決於這個項目的生命週期以及代碼的可移植性。如果這是一個一次性網站,需要最少的維護,它可能會節省您一些時間來放棄額外的抽象層,並在您的控制器中編寫Doctrine代碼。但是,如果您打算重新使用此代碼,將其移至不同的平臺或長時間維護它,我會花時間添加該抽象,因爲它會爲您提供更大的靈活性。

如果你還在研究框架,看看Kohana。它基本上是爲PHP5編寫的CodeIgniter輕量級重寫。

+0

這就是關於抽象的非常好的輸入。 關於框架,我從0.2版開始就使用了ZF,並且非常喜歡這個框架,它在很多項目中都使用它。從未聽說過Kohana,但會研究它。 – SuneKibs 2009-09-24 16:54:24

+0

@ pix0r,Kohana是CodeIgniter的重寫,而不是Symfony – 2009-09-24 16:58:35

+0

哈哈,你說得對。謝謝。 (編輯) – pix0r 2009-09-24 17:49:24

1

在你的研究中也考慮Symfony。它可以讓你使用ORM(propel/doctrine),或者你可以編寫你自己的數據模型。如果需要,您也可以繞過數據關係並使用直接SQL。

爲了解決您對1或2的擔憂,我個人會在我的項目中使用ORM,並在需要時繞過它。更好的是,在symfony中,如果你需要的話,你可以在教義和推動之間切換,或者你自己的類。

Pros: 
1) faster development. easier to maintain. generally more secure and consistent. easy to switch databases should you ever need to.(from MySQL to Oracle, etc). 

2) Faster runtime. Less dependency. 

Cons: 
1) Slower runtime and larger memory footprint. Dependency on other projects. 
2) (reverse the pros for #1) 
+1

感謝您的輸入,但我不想在#1和#2中使用Doctrine2,這只是一個問題,如果我不想抽象主義或我應該直接使用它。 – SuneKibs 2009-09-24 16:45:03

+0

對於symfony來說+1,它很有趣。 – 2009-09-24 17:14:35

2

我第二次來自pix0r的建議。如果額外的抽象是一個可能壽命較長的項目,並且可能有許多開發人員,那麼額外的抽象只是值得的。這幾乎是我遵循的指導原則,不管是在php中使用doctrine2還是在java中使用jpa(因爲doctrine2非常類似於jpa)。

如果您想要額外的抽象,doctrine2已經提供了使用存儲庫的可能性(存儲庫非常相似,甚至等於DAO,也許更注重業務術語和邏輯)。有一個基類Doctrine \ ORM \ EntityRepository。無論何時調用EntityManager#getRepository($ entityName),Doctrine都會查看是否爲該實體配置了自定義存儲庫類。如果沒有,它實例化一個Doctrine \ ORM \ EntityRepository。您可以在元數據中爲實體配置自定義存儲庫類,例如在docblock註釋中:@Entity(...,repositoryClass =「My \ Project \ Domain \ UserRepository」)。這樣的自定義類應該從EntityRepository繼承並適當地調用父構造函數。基類已經包含一些基本的find *功能。

羅馬

1

我的想法與pix0r的迴應相似。但是,如果你的項目足夠小,以至於你可以直接在控制器中使用EntityManager/DQL,那麼Doc​​trine 2對於你的項目來說可能是過度的,也許你應該考慮一個更小/更簡單的系統。

0

根據我的經驗,在控制器中編寫持久層邏輯總是會以技術債務的形式困擾我。這個看起來很小的決定現在可能會導致未來即使在小型項目中不可避免的和潛在的大規模重新分解。理想情況下,我們希望能夠複製和粘貼用相應模型重新配置的極薄控制器,以防止我們不得不反覆創建CRUD控制器,而且還允許定製這些控制器。在我看來,這隻能通過嚴格管理並儘可能地將持久層從我們的應用程序中抽象出來才能完成。由於在乾淨的房間控制器上執行這些操作的開銷很小,所以我看不到任何理由建議您不要。