自制SQL模型與ORM？

Question

我已閱讀關於ORM優點和缺點的Stack Overflow討論，並且有不同的觀點。我想描述這個特殊情況。

• 基於LAMP的中等規模網絡應用程序，裏面有一些意大利麪代碼。
• 的代碼是被OOP很遠，但也有嵌入式的模板，而弱模型類分支控制器。
• 有幾十個MySQL表，以及約萬個文件。
• 緩存，針對性能進行調整帶查詢的MySQL查詢。
• 每月大約有一百萬次瀏覽。
• 用戶主要閱讀權限。

我的問題是這樣的：

這是值得推行的ORM（Doctrine2或推進），或者我應該限制自己從劃痕（類似於ActiveRecord的模式，組方法寫模型類/按表和記錄查詢，所以每個實體有兩個相關的類）？

的主要目的是：

1. 應用性能，

2. 便於代碼/查詢可讀性和修改的，和

3. 便於可能的DB（細節）的修飾。

我個人更喜歡第二選擇;有相當複雜的SQL查詢，我懷疑一個ORM能夠維護所有查詢的數據庫抽象。最初的開發已經結束，代碼/查詢代碼的開發速度沒有了。能夠輕鬆閱讀，理解和修改代碼/查詢對我們來說更爲重要。

在另一隻手，有可能是在ORM使用的一些長處爲我想念給定的條件。

Answer 1

構建你的代碼一定會幫助你用2和3，如果使用得當，1應該也不吃虧。當您將第三方ORM集成時，應該更容易實現良好的性能，因爲這些ORM支持「緩存」和「開箱即用」延遲加載等功能。

我建議你嘗試重構你的應用程序中的小步驟，增加新的功能或解決的bug，從而避免難以自圓其說和管理龐大的重構項目同時進行。

我會說，對使用第三方ORM的好辦法是組織現有的代碼和查詢以類似的方式。因此，您可能會引入ProductRepository類，該類具有封裝現有查詢的方法find（）並返回ResultSet。接下來，您應該介紹產品數據類（只有字段且沒有方法的類）。產品類應該映射數據庫中的產品表。現在找到應該返回數組的產品。 find（）方法現在將首先將ResultSet轉換爲Products的數組並返回該數組。客戶端代碼應該相應地修改。最後，你開始使用ORM代理將find（）方法中的自定義查詢替換掉。使用存儲庫的客戶端不應檢測到更改。產品數據類是模型圖層的種子。隨着您的繼續，您可以添加行爲並創建一個真正的域圖層。回到你的問題，我想說你先以自定義Active Record的形式（我建議使用Repository，但最後它只是組織的問題）對現有代碼進行分組，然後引入ORM。所以，這不是 - 或者是情況，而是重構的第一和第二階段。

我會以下列方式處理這個：

1. 寫第一
2. 嘗試在不同的層單獨的代碼一些自動化測試：演示，域，持久性。
3. 按前面部分所述執行重構。

實現完全成熟，可重用的ORM有很多工作，所以我建議你將現有的併入，並開始小步驟介紹它。

我在C＃專業重構中詳細描述了這種方法，您可以下載示例代碼，通過here。