2015-12-22 138 views
1

在我們的Web應用程序中,我們擁有帶CRUD操作和通用查找程序功能的存儲庫,例如userRepository.Get(u => u.Username == someString)。 和UserRepository將只返回User對象。mvc中的代碼組織

但如果我有一個複雜的查詢其做加盟之間Table1Table2Table3並返回CustomObject包含這3代表的某些屬性。

我應該把這些查詢放在服務層嗎? 存儲庫是否只包含基本的CRUD和查找程序功能,並返回基本的實體對象而沒有其他內容?我問,因爲有人告訴我,沒有查詢應該在服務層...

+0

這是您需要查看Domain驅動設計的地方,您可以使用存儲庫執行此操作,但在應用程序複雜時它不是通用的 – brykneval

+1

您也可以查看此文章:http://programmers.stackexchange。com/questions/218011/how-accurate-is-business-logic-should-in-a-service-not-in-a-model – Peter

回答

1

我可能會創建一個類型CustomObjectRepository它封裝表的加入和返回只有CustomObject s。具體如何實現通用查找器函數取決於您使用的是哪種類型的ORM(對於EF來說這很簡單,複雜但如果執行手動映射則根本不可能)。

1

您可以擁有一個業務邏輯視圖導向倉庫,它根據該業務邏輯在當前倉庫的頂部和頂部放置一個級別。

或者您可能會將分配此查詢的分層邏輯應用到您現有的某個存儲庫。

例如。 如果您有3張桌子(Driver - Car- DriveSessions),並且您需要顯示用戶的名字,車牌,車牌和上次Drive會話的所有信息。

使用第一種方法,您將創建一個「Summaries」存儲庫。 或者你可以在「Driver」存儲庫中添加它,因爲所有這些實體都是以「Driver」爲導向的。

我的意見是在EF的頂部添加一個倉庫是一個矯枉過正。有些商業模式非常複雜,以至於無法在單個存儲庫中提取所有內容。這就是EF爲IQueryable設計的原因。將所有實體封裝在具體存儲庫後面,您將失去大部分糖果EF所提供的功能。

Opinions about using Repository pattern on top of EF

在我的應用我認爲不是一個單一的實體非複雜。使用具體的每個表存儲庫會降低性能並增加開發時間A LOT

+1

還有其他一些方法可以在EF之上編寫存儲庫, IQueryables,但仍提供ORM特定代碼的包裝層 - 例如http://blogs.msdn.com/b/mrtechnocal/archive/2014/03/16/asynchronous-repositories.aspx(當然,有仍然是客戶端代碼和EF之間的耦合,因爲對EF不支持的IQueryables的操作會拋出異常,但分離比直接使用EF好得多)。 –

+0

是的我使用了一種有點類似的方法,但我認爲我不會稱之爲經典的「存儲庫模式」。它主要是圍繞着我認爲的實體框架的包裝。 –

0

使用查詢對象模式。這是一個更堅實的方法。此外,分離查詢和CRUD,爲使用更適合定製查詢的不同更合適的基礎架構創造了機會。另請參閱:this

如果可以,請調查Vaughan Vernon所稱的「使用cas優化查詢」,並提防他稱之爲「存儲庫掩碼聚合錯誤設計」的氣味。