可持續性無知量表嗎？

Question

我一直在看NHibernate和Linq2Sql。我也打算查看實體框架。

即得到提高，當我跟這些ORM的是「他們不能規模化」的問題，這樣可以吧？從谷歌我得到他們能夠很好地擴展的印象，但最終我認爲必須付出代價，是否值得爲更簡單的業務層付費。

Answer 1

這是一個很好的問題，恕我直言，他們可以擴展一樣好任何自定義DAL。我只使用nHibernate，所以我只關注它和它具有的可以幫助擴展系統的功能。

• 延遲加載 - 由於它支持延遲加載，因此您可以避免加載任何unnessecary項目。當然，您需要注意選擇n + 1問題，但系統中有些東西可以防止這種情況發生。
• 渴望獲取 - 有各種方法可以熱切地獲取您可能需要的對象，從而避免額外訪問SQL。
• 二級高速緩存 - nHibernate支持二級高速緩存，可以通過減少到DB的行程來增加可伸縮性。有各種支持提供商可以提供一些靈活性。
• 編寫您自己的SQL - 在nHibernate中，您可以調用存儲過程，或者提供將返回實體的內聯SQL查詢。這將讓你使用自己的SQL時，生成的SQL不會削減它。例如，使用遞歸查詢加載自連接樹。

現在有了這樣的說法，我認爲最初調整一個自定義DAL層比較容易，因爲您的構造很親密，可以對它進行微調;然而，一個好的ORM將提供大量的鉤子，讓你可以優化很多。你只需要花一些時間來學習它。

我也覺得，如果你有一個代碼性能的關鍵領域，你不能讓你的ORM您的要求範圍內工作，那麼你的應用程序，你可以自定義生成自己的DAL層的面積很小。如果您使用的是像樣的設計模式，例如由工廠創建的Repository，那麼您所需要做的就是替換您的存儲庫的實施。

Answer 2

Hibernate Shards正在ported to NHibernate，這將允許水平縮放。

也有一些非常酷的黑客喜歡this one實行分片。

因此，答案是肯定的，NHibernate的可以縮放，在持久性，無知和完全透明的方式。

Answer 3

這是不正確的說，ORM內置的應用程序不能很好地擴展。當然，它發生在那些粗心大意或懶惰的開發者通過編寫生成可怕的低效SQL的代碼來濫用ORM。構建高性能應用程序意味着理解有關所有可愛的抽象實際上在做什麼。然而，避開這個陷阱並不需要太多。使用ORM並不意味着從不打開SQL分析器或NHibernate Profiler。

而關於SP快得多的說法，請閱讀this和this。此外，ORM（NHibernate，至少）給你很容易的方式來使用SPs，如果你需要的話。