我一直在使用Entity Framework
和repository pattern
一段時間了。存儲庫模式僅用於實體框架嗎?
我被問到有一天不使用實體框架寫的數據層,只是普通的舊ADO.NET
。我想知道什麼是最好的方法呢?我是否還使用普通的舊ADO.NET對我的CRUD操作使用存儲庫模式?
如果我轉到Codeplex
並搜索存儲庫模式,則所有示例項目中有99.9%使用實體框架。如果我使用普通的ADO.NET和存儲過程,是否需要使用不同的模式?
我一直在使用Entity Framework
和repository pattern
一段時間了。存儲庫模式僅用於實體框架嗎?
我被問到有一天不使用實體框架寫的數據層,只是普通的舊ADO.NET
。我想知道什麼是最好的方法呢?我是否還使用普通的舊ADO.NET對我的CRUD操作使用存儲庫模式?
如果我轉到Codeplex
並搜索存儲庫模式,則所有示例項目中有99.9%使用實體框架。如果我使用普通的ADO.NET和存儲過程,是否需要使用不同的模式?
不,存儲庫模式在實體框架之外被廣泛使用,並且是處理數據訪問的全面有用的方式。
從MSDN
http://msdn.microsoft.com/en-us/library/ff649690.aspx
其他好處:
userRepository.FindByEmailAddress(emailAddress);
Martin Fowler的「企業架構模式」,提供了一種用於存儲庫中的以下定義:使用用於訪問域對象的集合狀界面域和數據映射層之間
介導。
的常用方法來實現,在C#是有一個通用的Repository<T>
類,其中T是一個實現IQueryable<T>
並提供像Add(entity)
,Remove(entity)
另外的方法持久對象。
沒有ORM就很難實現。您可以創建一個更簡單的存儲庫,將SQL語句作爲WHERE條件使用,但可能會變得混亂。
許多示例對具有不同持久性方法的每種類型使用具體的存儲庫類。但那些只是僞裝的DAO類。
我不完全同意你的看法。當他定義模式時,泛型甚至不存在。它們是使用內存中的集合來模擬它的衆多例子。 – scartag 2013-04-10 16:39:19
我剛剛提供了實現存儲庫的常用方法。您絕對可以簡化實現以使用SQL語句返回並實現對象。 – 2013-04-10 16:40:28
通用存儲庫不好,只有一個例外:您的所有存儲庫看起來都是一樣的,並且在同一個地方持續存在(例如,以序列化形式將所有內容存儲在一個表中的域存儲庫)。存儲庫公開的Iqueryable是一種反模式,原因有兩個:1)它假定業務對象與底層數據存儲實體相同,大多數情況下ORM實體和Iqueryable指定如何構建查詢回購的關注。你不告訴存儲庫如何做東西,你告訴它你想要什麼。 – MikeSW 2013-04-11 05:49:59
我不認爲這是正確的方法。但有一些假設
在EF代碼上添加一個存儲庫模式。這使您遠離ORM的功能。實體框架已經是數據庫的抽象層。
如果您想使用EF上的依賴注入和測試驅動開發,那麼您需要遵循Repository Pattern。通過使用RP,您的代碼變得可測試和可注入/可維護。
開箱即用的EF並不是非常容易測試的,但通過可以注入的接口製作EF數據上下文的可模擬版本非常容易。
如果我們不希望我們的代碼是可測試或可注射的,那麼就不要使用RP。
我看到一篇博文:http://www.nogginbox.co.uk/blog/do-we-need-the-repository-pattern
但你有沒有看到這篇文章? http://www.sapiensworks.com/blog/post/2012/10/10/Do-We-Need-The-Repository-Pattern.aspx;) – MikeSW 2013-04-13 19:14:00
我沒有看過這篇文章。也許我應該寫一篇名爲「我應該何時使用ORM存儲庫模式」的新的nogginbox博客文章。很多很好的理由在Sapiens工作的文章中,爲什麼你會。如果你只是想包裝你的ORM來使其可測試,那麼不需要。如果您有多個要隱藏的數據源,或者計劃稍後換出數據層,那麼也許是。 – 2017-12-13 10:20:32
不,絕對不是。存儲庫模式是數據訪問的通用模式 - 無論您訪問數據的方式如何,都可以在訪問數據時使用。 – 2013-04-10 16:34:01
實際上,使用存儲庫模式的整個*點*是將您的應用程序與訪問數據的方式隔離開來。 EF常常是對該框架有多麼有用的證明,或者是在dotnetland中缺乏替代品。 – millimoose 2013-04-10 16:36:43