我在開始一個新項目，創造我只是用普通的舊CLR對象，而不是任何的ORM的業務對象和數據訪問等的過程lazying加載。我創建了兩個類庫： 1）Business Objects - 擁有我所有的業務對象，所有這些對象的重量都很輕，只有屬性和業務規則。 2）存儲庫 - 這是爲我所有的數據訪問。Repository模式使用POCO
我的大部分對象將在子列表，我的問題是什麼是延遲加載這些值，因爲我不想帶回不必要的信息，如果我不需要的最佳途徑。
我想到了用「得到」的子屬性，以檢查其是否「空」時，關於如果是叫我的資料庫，以獲得孩子的信息。這有兩個問題，我可以看到： 1）對象「知道」如何獲得自己我寧願沒有數據訪問邏輯被保存在對象中。 2）這需要兩個類互相引用，在Visual Studio中引發循環依賴錯誤。
有沒有人對如何克服這個問題，或者我的項目佈局的建議任何建議，它可以改善？
感謝
在調查提供的答案和進一步的研究後，我發現一篇文章使用委託進行延遲加載。這提供了一個比使用代理或實現NHibernate更簡單的解決方案。這篇文章的link。
讓您可以循環依賴問題，如果你懶加載代碼在運行時加載庫（Activator.CreateInstance或類似的東西），然後調用通過反射適當的方法。當然還有與反思相關的績效懲罰，但在大多數解決方案中往往是微不足道的。
另一種方式來解決這個問題是簡單地編譯成一個DLL - 在這裏你可以仍然使用不同的命名空間邏輯上獨立的層，並且仍然使用不同的目錄類進行分類整理。
要做到這一點，需要你對編程接口（抽象以上實現）和/或聲明你的屬性是虛擬的。然後你的倉庫會爲那些懶惰地加載的屬性返回一個代理對象。調用存儲庫的類並不聰明，但當它嘗試訪問其中一個屬性時，代理將調用數據庫並加載值。
坦率地說，我認爲試圖實現這一點是瘋狂的。這個問題有很多經過時間考驗的解決方案，這些解決方案都是由.NET中最偉大的思想開發和完善的。
要進行代理，您可以使用Castle DynamicProxy，或者您可以使用NHibernate並讓它爲您處理所有代理和延遲加載（它使用DynamicProxy）。保證性能比任何手動實現都要好。我們不會讓你的POCOs混淆 - 沒有屬性，沒有基類，你只需要標記虛擬成員以允許代理生成。
簡而言之，我會重新考慮使用ORM，特別是如果你想要延遲加載;你不必放棄你的POCO。
如果您使用的是實體框架4.0，您將支持POCO的延遲加載&將允許您編寫通用存儲庫來執行數據訪問。
在EF 4上有大量關於通用存儲庫模式的文章。0
HTH。