Jakie są niektóre argumenty PONOWNIE za pomocą EntityFramework? [Zamknięte]

31

Aplikacja, którą obecnie buduję, używa procedur przechowywanych i ręcznie wykonanych modeli klas do reprezentowania obiektów bazy danych. Niektóre osoby zasugerowały użycie Entity Framework i rozważam przejście na to, ponieważ nie jestem tak daleko w projekcie. Mój problem polega na tym, że ludzie, którzy kłócą się o EF, mówią mi tylko dobrą stronę rzeczy, a nie złą stronę :)

Moje główne obawy to:

Chcemy sprawdzania poprawności po stronie klienta za pomocą DataAnnotations i wygląda na to, że i tak muszę tworzyć modele po stronie klienta, więc nie jestem pewien, czy EF zaoszczędziłby tyle czasu na kodowanie
Chcielibyśmy, aby klasy były jak najmniejsze podczas przechodzenia przez sieć, i przeczytałem, że używanie EF często zawiera dodatkowe niepotrzebne dane
Mamy złożoną warstwę bazy danych, która przecina wiele baz danych, i nie jestem pewien, czy EF sobie z tym poradzi. Mamy jedną wspólną bazę danych zawierającą informacje o użytkownikach, kodach statusu, typach itp. Oraz wiele instancji naszych głównych baz danych dla różnych instancji aplikacji. Zapytania SELECT mogą i będą wykonywać zapytania we wszystkich instancjach baz danych, jednak użytkownicy mogą modyfikować tylko obiekty znajdujące się w bazie danych, nad którą aktualnie pracują. Mogą przełączać bazy danych bez ponownego ładowania aplikacji.
Tryby obiektowe są bardzo złożone i często wiąże się z nimi całkiem sporo połączeń

Argumenty za EF to:

Konkurencja. Nie musiałbym kodować czeków, aby sprawdzić, czy rekord był aktualizowany przed każdym zapisem
Generowanie kodu EF może generować dla mnie modele klas cząstkowych i POCO, jednak nie jestem pewien, czy naprawdę zaoszczędziłoby mi to tyle czasu, ponieważ uważam, że nadal będziemy musieli stworzyć modele po stronie klienta do sprawdzania poprawności i niektóre niestandardowe metody analizy.
Szybkość rozwoju, ponieważ nie musielibyśmy tworzyć procedur przechowywanych CRUD dla każdego obiektu bazy danych

Nasza obecna architektura składa się z usługi WPF, która obsługuje wywołania bazy danych za pomocą sparametryzowanych procedur przechowywanych, obiektów POCO, które przechodzą do / z usługi WCF i klienta WPF, oraz samego klienta stacjonarnego WPF, który przekształca POCO w modele klasowe w celu walidacji i DataBinding.

Więc moje pytanie brzmi: czy EF jest do tego odpowiedni? Czy są jakieś pułapki związane z EF, o których nie wiem?

architecture orm entity-framework

— Rachel
źródło

Sprawdź to też .. porównanie wydajności i obsługi LINQ: ormeter.net

— M.Sameer

7

Ostatnio oceniałem Entity Framework, a najlepszym miejscem, w którym znalazłem problemy i brakujące funkcje, było: http://data.uservoice.com/forums/72025-ado-net-entity-framework-ef-feature-suggestions

Elementy z największą liczbą głosów:

Wsparcie dla wyliczeń. Ten jest dość duży, ale obecnie istnieją pewne obejścia
Ulepszone generowanie SQL. Szybkość jest naprawdę ważna, szczególnie w przypadku aplikacji na poziomie korporacyjnym, ale wydaje się, że w przypadku EF4 znacznie się poprawiła
Obsługa wielu baz danych. Wymagania dla każdej dużej aplikacji.

Istnieje wiele innych problemów na liście Głos użytkownika.

Na marginesie, jestem bardzo podekscytowany nadchodzącą wersją EF 4.1, która obejmie podejście Code-First ... http://blogs.msdn.com/b/adonet/archive/2011/03/15/ef-4 -1-release-kandydat-dostępny.aspx

Może mnie to zmusić do wypróbowania EF w aplikacji produkcyjnej.

— Mag20
źródło

Argument przeciwko: 1. i 2. i 3.: WOLNO !!! Istnieje krzywa uczenia się (trzeba wiedzieć, jak wykonać lewe łączenie - znalezienie sposobu, jak to zrobić, zajmuje 3 godziny, aby inna osoba wiedziała, co się robi ...), stronicowanie w LINQ zamiast SQL (np. Fekalia 10 milionów wierszy, a następnie bierze 20 z arbitralnego przesunięcia, a potem zastanawiasz się, dlaczego jest tak wolny) ... Repo nie jest bezpieczne dla bieżnika, musisz go inicjować na podstawie zapytania, a inicjalizacja repo jest BARDZO SPOWOLNIENIE (około 5 sekund), jeśli masz większą bazę danych (to znaczy 100-200 tabel, NIE NAPRAWDĘ NAPRAWDĘ duże).

— Quandary

2

@Quandary Wydaje się, że wykonujesz IQueryables (tj. Wywołując .ToList()lub .ToArray), zanim wyrażenia LINQ zostaną w pełni zdefiniowane. Dlatego pobiera wszystkie rekordy i spowalnia.

— orad

6

Robienie gałęzi na błąd / funkcję za pomocą EF może być wyjątkowo bolesne w czasie łączenia. Wyobraź sobie, że dwie gałęzie A i B dokonują zmian w bazie danych (co prawdopodobnie zdarzy się często na wczesnych etapach nowego projektu).

Łączysz wszystkie „normalne” pliki - pliki cs itp. A potem nadszedł czas na połączenie Model.edmx. I nagle nie tylko scalasz logiczne odwzorowania między modelem obiektowym i bazą danych, ale także pozycjami tabel na diagramie encji.

Scalanie Model.edmx jest tak bolesne, że przyjęliśmy dość nieprzyjemny sposób, który działa:

Podczas scalania wybierz wszystkie scalenia jednego rodzica. Co nie ma znaczenia; i tak wkrótce toast za plik:
Przywróć Model.edmx do jednego z rodziców.
Przeprowadź migrację bazy danych do nowego stanu scalonego.
Otwórz Model.edmx i „Aktualizuj model z bazy danych”.
Zmień nazwy wszystkich właściwości nawigacyjnych opiekanych podczas scalania.

— Frank Shearar
źródło

1

Ta krytyka nie dotyczy najpierw kodu EF, ale dotyczy najpierw modelu i bazy danych.

— Alan Macdonald

Wszystkie mapowania tworzę samodzielnie przy użyciu Fluent i przejmuję pełną kontrolę nad mapowaniem. Są one umieszczane w osobnym pliku .cs.

— Steven Ryssaert

5

Istnieje kilka innych korzyści dla EF, których brakuje:

Możesz mieć tabele zakresu jednostek
Możesz podzielić tabelę na wiele rodzajów encji
Możesz wygenerować encje z bazy danych (tj. Baza danych jako podejście główne)
Możesz wygenerować bazę danych z Encji (tj. Kod jako podejście główne)
Zapytania LINQ są tłumaczone na zapytania SQL, co poprawia ich wydajność.

Wady (szczególnie jeśli korzystasz z walidacji):

Musisz utworzyć atrybut [MetadataClass], który wskazuje na inną klasę, która ma właściwości, które chcesz sprawdzić za pomocą odpowiednich atrybutów sprawdzania poprawności. Wszystkie właściwości są objecttypami, więc po prostu odczytaj metadane. Wciąż dużo dodatkowego nieaktywnego kodu.
Korzystanie z EntityFramework jest inną koncepcją niż sposób, w jaki działa coś takiego jak NHibernate (a także nadrzędna wersja Java). EntityFramework działa najlepiej w trybie dołączonym , w którym obiekty przez cały czas używają połączenia na żywo. NHibernate i podobne narzędzia ORM działają najlepiej w trybie odłączonym , w którym połączenie jest używane tylko podczas ładowania / zapisywania danych.

To dwie największe skargi, jakie mam. Jest wiele korzyści, ale bardzo dobrze możesz uzyskać te same korzyści z NHibernate. Jeśli EntityFramework jest na stole, poproś zespół, aby sprawdził również NHibernate i zrobił krótką strzelaninę za / przeciw za twój projekt.

Problem z klasą metadanych powoduje ból głowy, ale na szczęście mam tylko tyle jednostek, które potrzebują tagów sprawdzania poprawności.

Brak prawdziwego trybu odłączonego dla obiektów ogranicza to, co można zrobić w środowisku sieciowym. Tryb dołączony jest lepszy dla aplikacji komputerowych, stąd powstało wiele innowacji Microsoft. Tryb odłączony jest możliwy , ale bardzo bolesny. W takim przypadku najlepiej jest użyć alternatywnego narzędzia.

— Berin Loritsch
źródło

Twój tak zwany kod jako podejście główne jest oficjalnie nazywany najpierw kodem

— Robert Koritnik

1

@ Berin, chcę wyjaśnić, co rozumiesz przez „tryb dołączony”. Nie sądzę, że Entity Framework ma połączenie z bazą danych otwartą przez cały czas. Pod tym względem uważam, że EF działa podobnie do NHibernate. Czy to masz na myśli, czy masz na myśli coś innego? Czy masz link do dokumentacji, która wyjaśnia ten załączony problem?

— RationalGeek

1

Przez dołączony, to znaczy wszystkie interakcje z obiektami musi nastąpić w terminie do using(EFConnection conn = new EFConnection)konstruktu. Jeśli spróbujesz schować gdzieś ten obiekt w celu bezpiecznego przechowywania, abyś mógł wykonać szybką aktualizację i zapisać go ponownie w drugiej using(...)instrukcji, musisz pomyśleć jeszcze raz. Zobacz msdn.microsoft.com/en-us/library/bb896271.aspx i msdn.microsoft.com/en-us/library/bb896248.aspx . Używanie EF 3.5 (którego musiałem użyć w ostatniej wersji) nie jest nawet tak czyste.

— Berin Loritsch,

Ok, rozumiem co masz teraz na myśli. Chciałem tylko upewnić się, że ludzie nie biorą tego pod uwagę, że zawsze istnieje połączenie z bazą danych . Musisz mieć kontekst obiektu, który utrzymuje stan „dołączonych” bytów.

— RationalGeek

2

To nie jest prawda. EF ma silne pojęcie o odłączonych jednostkach. Odłączony byt musi zostać ponownie przyłączony do swojego kontekstu, zanim będzie można wykonać przeciwko nim operacje związane z kontekstem (takie jak aktualizacja go w bazie danych). Również klasy metadanych są konieczne tylko wtedy, gdy EF wygeneruje dla ciebie swoje encje. POCO, IMO, są znacznie lepszym sposobem korzystania z EF. Korzystanie z POCO znacznie upraszcza wiele rzeczy, w szczególności testowanie.

— Matt Greer

2

Jedną rzeczą, Microsoft nie jest bardzo dobra w jest wstecznie ~~porównywalność~~ kompatybilności, szczególnie jeśli chodzi o nowe technologie

W szczególności EF1 (.net 3.5) bardzo różni się od EF4 (.net 4.0) - to samo może wystąpić w następnej wersji.

Poczekam chwilę i zobaczę, jak technologia dojrzewa.

W międzyczasie zastanów się nad użyciem nHibernate - nie jest równoważne, ale jest dojrzałe i dziko używane.

— Ophir Yoktan
źródło

1

Po prostu ... model domeny rzadko jest repliką modelu relacyjnego w bazie danych. Tak więc mapowanie niektórych tabel na klasę i rzucanie ich na drut jest po prostu lenistwem. Tabele mogą lokalnie zamapować się na 1 obiekt, nawet jeśli baza danych zawiera 3 różne tabele. Inteligentnie zaprojektuj bazę danych.
Po drugie, te pliki EF nie mogą generować pewnych zapytań i i tak musisz je napisać.
3. Model domeny nie mapuje bezpośrednio na usługi. Będziesz chciał tylko przesyłać jak najmniej DTO najbardziej minimalny zestaw danych, zwłaszcza jeśli będzie komunikował się z aplikacjami mobilnymi.
5 Zdolność do testowania ... Nie można stworzyć wystarczająco szczegółowych testów, które zapewnią wystarczającą regresję w stosunku do zmian kodu ... wszystko to jest łatwe do
złamania ...

Mógłbym napisać 10 stronicową diatrybę. Ale jeśli tylko piszesz jakąś wyrzuconą aplikację dla Firmy X, kogo to obchodzi. Ale jeśli tworzysz oprogramowanie, musisz być bardziej analny

— użytkownik104468
źródło

ten post jest raczej trudny do odczytania (ściana tekstu). Czy mógłbyś edytować go w lepszym kształcie?

— komara

EF nie generuje obiektów domeny. To są DAO. Musisz użyć danych z obiektu, aby utworzyć obiekt domeny. Zresztą nie powinieneś odsyłać obiektów domeny z usługi, dlatego przed powrotem powinieneś utworzyć cieńsze DTO ze swoich obiektów domeny. EF powinien być w stanie wygenerować większość wszystkiego, co możesz wyrazić w LINQ. Baza danych nie jest częścią testu jednostkowego, jest częścią testu funkcjonalnego. To powiedziawszy, są dostępne makiety pamięci dla EF. W przeciwnym razie wyodrębnij zapytania EF do repozytorium, a następnie wyśmiewaj to.

— Sinaesthetic

Tak, zgadzam się. Odnoszę się raczej do wzorów ustalonych przez Martina Fowlera i Cariga Lairmana. Na koniec dnia nie mogę korzystać z CTE, PARTITION BY ani CROSS APPLY. Ja również nie mogę użyć IDataReadera, który pozwala utrzymać niski poziom pamięci. Ponadto, gdy uruchamiam śledzenie SQL i widzę, co EF przesyła przez drut, czuję się, jakbym mógł rzucić ;-)

— user104468

0

Sprawdź to: http://efvote.wufoo.com/forms/ado-net-entity-framework-vote-of-no-confidence/

Główne punkty to:

Brak leniwego ładowania
Brak uporczywości ignorancja
Format pliku używany do zapisywania modelu encji zawiera zarówno elementy wizualizacji, a sam model encji powoduje problemy z scalaniem w środowisku zespołu.

Zauważ, że powyższy link mówi o EF1.

Również ten link: http://ormeter.net/ pokazuje, że EF nie jest najlepszy w porównaniu z innymi ORM pod względem wydajności i obsługi LINQ.

— M.Sameer
źródło

Pamiętaj, że zostało to opublikowane, gdy EF 1 był jeszcze nowo wydany (lub być może jeszcze w wersji beta). Sytuacja jest dziś znacznie lepsza w przypadku EF 4, a wiele kwestii poruszonych w głosowaniu nad wotum nieufności zostało rozwiązanych.

— RationalGeek

Ostatni punkt wciąż się liczy i jest bardzo znaczący.

— M.Sameer,

1

Pierwsza wersja EF miała 3.5. Nie wydano czterech głównych wersji EF.

— Matt Greer,

3

@Matt, który jest poprawny. Ale bieżąca wersja nazywa się EF 4 w celu dopasowania do reszty wersji .NET 4.

— RationalGeek

1

Jednak to, czy jest poprawne czy nie, nie powinno wpływać na podsumowanie linku. Głosy pokażą, czy są ważne. :)

— Adam Lear