Czy wzór repozytorium ma być używany tylko z Entity Framework?

Używam od pewnego czasu Entity Framework i repository pattern.Czy wzór repozytorium ma być używany tylko z Entity Framework?

Któregoś dnia zostałem poproszony o napisanie warstwy danych bez użycia Entity Framework, po prostu stary ADO.NET. Zastanawiałem się, jakie byłoby najlepsze podejście? Czy używam również wzorca repozytorium dla moich operacji CRUD przy użyciu zwykłego starego ADO.NET?

Jeśli przejdę do Codeplex i wyszukuję wzór repozytorium, wówczas 99,9% wszystkich przykładowych projektów będzie korzystać z Entity Framework. Czy istnieje inny wzorzec, który musi być użyty, jeśli używam zwykłego ADO.NET z procedurami przechowywanymi?

Źródło

2013-04-10 Brendan Vogt

NIE, zdecydowanie nie. Wzorzec repozytorium jest wzorcem ogólnego przeznaczenia dla dostępu do danych - może być używany za każdym razem, gdy uzyskujesz dostęp do danych - bez względu na to * jak * dokładnie uzyskujesz dostęp do danych. –

W rzeczywistości cały * punkt * używania wzorca repozytorium polega na odizolowaniu aplikacji od sposobu dostępu do danych. Często EF jest świadectwem tego, jak użyteczne są te ramy, lub brakiem alternatyw w dotnetlandzie. – millimoose

Nie, wzorzec repozytorium jest szeroko stosowany poza strukturą Entity Framework i jest wszechstronnym użytecznym sposobem obsługi dostępu do danych.

Od MSDN

Centralizuje logikę dostępu logicznego dane lub usługi sieci Web.
Zapewnia punkt zastępczy dla testów jednostkowych.
Zapewnia elastyczną architekturę, którą można dostosować, zmieniając ogólny wygląd aplikacji.

http://msdn.microsoft.com/en-us/library/ff649690.aspx

Inne korzyści:

Proste dodać logikę w repozytorium, takie jak wyniki buforowania ponad żądanie internetowej
wspólne zapytania mogą być dodane, takie jak userRepository.FindByEmailAddress(emailAddress);
Repozytorium można zmienić na inne, takie jak przełączanie bazy danych do usługi internetowej przy minimalnym wysiłku.

Źródło

2013-04-10 16:34:11

Martin Fowler w „Patterns of Enterprise Architecture”, podaje następującą definicję repozytorium:

pośredniczy pomiędzy warstwami domen i danych kartograficznych z wykorzystaniem interfejsu zbierającego podobny do dostępu do obiektów domeny.

Typowym sposobem realizacji że C# jest mieć ogólny Repository<T> klasy, w której T oznacza trwałe obiekt, który realizuje IQueryable<T> i dostarcza dodatkowych metod, takich jak Add(entity), Remove(entity).

Byłoby bardzo trudno wdrożyć bez ORM. Możesz utworzyć prostsze repozytorium, które pobiera instrukcje SQL jako warunki WHERE, ale może stać się niechlujne.

Liczne przykłady wykorzystują klasy konkretnych repozytoriów dla każdego typu z różnymi metodami utrwalania. Ale to tylko ukryte klasy DAO.

Źródło

2013-04-10 16:37:55

Nie całkiem się z tobą zgadzam. Rodzaji nie istniały nawet wtedy, gdy zdefiniował wzór. I są to liczne przykłady, które wykorzystują kolekcje w pamięci do symulacji. – scartag

Właśnie podałem typowy sposób na wdrożenie repozytoriów. Możesz zdecydowanie uprościć implementację, aby użyć instrukcji SQL do zwrócenia i zmaterializowania obiektów. –

Generyczne repozytoria są złe z jednym wyjątkiem: wszystkie repozyty wyglądają tak samo i zachowują się w tym samym miejscu (np. Repozytoria domen przechowujące wszystko w jednej tabeli w postaci szeregowej). Iqueryable odsłonięty przez repozytorium jest anty wzorkiem z dwóch powodów: 1) zakłada, że obiekt biznesowy jest identyczny z podstawową jednostką magazynu danych, w większości przypadków jednostka ORM i 2) Iqueryable określa, JAK zbudować zapytanie, gdy jest to obawy repo. Nie mówisz repozytorium, JAK robić rzeczy, mówisz to, czego chcesz od niego. – MikeSW

Nie sądzę, że to jest właściwa droga. Są jednak pewne założenia: Dodawanie wzorca repozytorium do kodu EF. W ten sposób możesz odciąć się od funkcji ORM.Entity Framework jest już warstwą abstrakcji w bazie danych.

Jeśli chcesz używać Dependency Injection i Test Driven Development przez EF, postępuj zgodnie ze wzorcem repozytorium. Za pomocą RP twój kod staje się testowalny i iniekcyjny/konserwowalny.

Po wyjęciu z pudełka EF nie jest bardzo testowalny, ale całkiem łatwo jest stworzyć mocną wersję kontekstu danych EF z interfejsem, który można wstrzyknąć.

Jeśli nie chcemy, aby nasz kod mógł być testowalny lub wstrzykiwany, po prostu nie używaj RP.

Widziałem post na blogu: http://www.nogginbox.co.uk/blog/do-we-need-the-repository-pattern

Źródło

2013-04-11 09:28:11 JSJ

Ale widziałeś ten post? http://www.sapiensworks.com/blog/post/2012/10/10/Do-We-Need-The-Repository-Pattern.aspx;) – MikeSW

Nie widziałem postu. Być może powinienem napisać nowy post na blogu na nogginie pod tytułem "Kiedy powinienem użyć wzorca repozytorium z ORMem". Wiele ważnych powodów w poście Sapiens Work na temat tego, dlaczego tak. Jeśli chcesz owinąć ORM, aby był testowalny, to nie. Jeśli masz wiele źródeł danych, które chcesz ukryć, lub planujesz zamienić warstwę danych później, może tak. –

Czy wzór repozytorium ma być używany tylko z Entity Framework?

Odpowiedz

Powiązane problemy