2011-04-12 31 views
3

我目前正在爲使用C#和Razor使用ASP.NET MVC3開發的Web應用程序重構我的代碼。爲了更好地構建我的應用程序,我使用的模式之一是Repository pattern,它除了是一個非常有用的模式之外,也是開發人員社區中經常討論的問題。根據存儲庫模式,存儲庫應該提供查詢還是實際的實體?

在這方面,我通過Fredrik Normen其中指出,根據庫的定義,一個庫類必須(在.NET例如列表)提供實際的實體,而不是可查詢的(在.NET IQueriable)對象中發現的文章。相反,在ASP.NET MVC官方網站的NerdDinner tutorial中,當存儲庫必須提供同一對象的多個實例以及存儲庫必須提供該對象的單個實例時的實際實體時,它們使用IQueriable。

根據存儲庫模式對存儲庫類/接口進行建模時,最正確的方法是什麼?

感謝

弗朗西斯

+0

可能的重複:http://stackoverflow.com/questions/1699607/asp-mvc-repository-that-reflects-iqueryable-but-not-linq-to-sql-ddd-how-to-ques – 2011-04-12 10:31:24

回答

4

在我看來這樣的事情是不利於利用你的時間。 ;-)

理論上,您的存儲庫應該返回它們的對象或傳統集合,是的。但是,即使您鏈接到的存儲庫模式的定義使用術語「類似集合的接口」。當然,IQueryable<Entity>是一個「類似收藏」的界面,是嗎?

實際上,我幾乎從不考慮區別......但我總是試圖將所有查詢代碼放入存儲庫中。我會說90%的基於集合的存儲庫方法返回傳統集合,而其他10%返回基於IQueryable<>的東西。例外通常與分頁有關;因此如果需要,我可以從行得到總計,如果需要的話,如果我不需要,就不必提前獲取該信息。這有點懶,但它適用於我。

但我認爲這是一個好主意,總是嘗試返回傳統的收藏,因爲這將意味着要封裝所有的查詢在庫中,這是它應該是。我建議不要過分追求極端水平,堅持某人對圖案的要求的想法-X

+0

感謝你的答案。我同意,在開發的第一階段,您更關心如何讓應用程序正常工作,並且在存儲庫之外進行一些查詢更爲方便。但是當你重構時,你總是試圖遵循提高應用程序質量的指導方針和模式。目前我的應用程序使用數據庫來存儲/獲取數據,但將來會使用Web服務。我想知道在上面列出的兩種方法中,最方便的存儲方法將減少這種「替代」的工作量。謝謝 – CiccioMiami 2011-04-12 09:38:31

+0

根本沒有「差異」。書呆子晚宴應用程序不會在存儲庫外查詢,以回憶我的情況。如果是這樣,這可能只是說明其他一點。將您的查詢代碼保存在存儲庫中,是的;只是不必太擔心返回究竟是什麼樣的「類似集合的接口」的確切語義。如果你喜歡更嚴格的要求,你會堅持下去,如果你堅持的話。 – 2011-04-12 09:40:39

+1

感謝您的回答。你應該得到這個標記 – CiccioMiami 2011-04-12 09:47:43

1

意見會因此而有所不同,因爲您已經發現了。對於小規模應用程序,讓您的存儲庫公開IQueryable可能是可以的。

你肯定不應該做的一件事是傳遞IQueryable到你的意見。確保你的視圖只接收物化對象和集合(如List或數組)。 這樣,如果某個查詢中存在錯誤,它將發生在控制器(或存儲庫)中,而不是在您的視圖中。這使您能夠測試查詢和處理錯誤優雅。

+0

爲什麼不傳遞給觀點?有什麼不同?這是否使抽象泄漏較少? – 2011-04-12 09:23:55

+0

@Marnix van Valen:謝謝你的回答。我總是強迫自己不要使用ViewData,而是使用ViewModel來增強測試。我認爲這是避免將IQueriables傳遞給View的最好方法。請您註明您認爲哈_「小規模申請」_?謝謝 – CiccioMiami 2011-04-12 09:40:56

+0

@Arnis IQueryable可能會做懶惰的評估,具體取決於下面的查詢和存儲。最糟糕的情況是它會在渲染視圖時對數據庫執行多個查詢。有很多事情可能會出現問題。你可能想閱讀[這篇文章](http://www.weirdlover.com/2010/05/11/iqueryable-can-kill-your-dog-steal-your-wife-kill-your-will-to- live-etc /)以獲取更多信息。 – 2011-04-12 12:04:40