Czy powinniśmy używać Entity Framework?

31

Obecnie mamy następujący stos:

  • VS 2005
  • Formularze internetowe
  • SQL Server 2005
  • IIS 6

Planujemy przejść do tego:

  • VS 2010
  • MVC i formularze internetowe
  • SQL Server 2008
  • IIS 7

Moje pytanie brzmi: kiedy przechodzimy do MVC z VS 2010, czy powinniśmy używać Entity Framework (lub innego ORM), mikro ORM (jak Massive ), czy po prostu zwykłego SQL?

Wszystkie samouczki, które przeczytałem o VS 2010, mają na celu wykorzystanie Entity Framework do transakcji danych, ale czy będzie to możliwe w najbliższej przyszłości (ponad 5 lat)?

Jeśli ma to znaczenie, aplikacje naszego klienta mogą mieć od 10 do 1000 aktywnych użytkowników.

guanome
źródło
Czy używasz obecnie Linq-to-SQL?
Morgan Herlocker,
Używamy sparametryzowanego SQL
guanome
4
Unikaj używania SQL bezpośrednio w swoim przyszłym rozwoju. ORM lub EF są prawie koniecznością. Poświęć trochę czasu na strategię dla warstwy dostępu do danych. To krytyczna decyzja i nie jest to trywialne zadanie. Upewnij się, że masz wystarczająco dużo czasu dla siebie i zespołu, aby się tego nauczyć. Należy zarządzać wprowadzeniem nowej podstawowej technologii do zespołu. Wybierz narzędzie, wybierz materiał, zdobądź wykształcenie, ... a następnie oceń i zdecyduj.
NoChance,
2
Nowe czy istniejące bazy danych? Potencjalnie istnieje ogromna różnica między budowaniem nowego DB z myślą o konwencjach EF, a próbą modernizacji EF na istniejącym DB, który nie został zbudowany dla ORM.
rmac
@rmac To była nowa baza danych.
guanome

Odpowiedzi:

45

Niedawno przestawiłem się z używania wbudowanych zapytań SQL na używanie EF i oto, co znalazłem:

Plusy

  • Znacznie szybciej buduje DAL (uwielbiam nie pisać zapytań SQL!)
  • O wiele łatwiejsze w utrzymaniu
  • Nie trzeba już pamiętać o analizie moich danych wejściowych przed zbudowaniem wbudowanej instrukcji SQL, co oznacza mniejsze prawdopodobieństwo ataku iniekcyjnego SQL (oczywiście nadal jest to możliwe w zależności od zapytań, ale znacznie mniej prawdopodobne)

Cons

  • Nie można rozciągać na wiele baz danych ... przynajmniej nie łatwo
  • Wszystkie jednostki (tabele, widoki itp.) Potrzebują klucza podstawowego
  • Jeśli chcesz zaktualizować jedną kolumnę w tabeli wymagającej ponad 100 kolumn (nie w moim projekcie tabeli), musisz pobrać wszystkie 100 kolumn, aby dokonać aktualizacji. Lub użyj procedury składowanej.
  • Miałem problemy z tym, że niektóre wartości domyślne zdefiniowane na serwerze SQL nie były wciągane do modelu encji po dodaniu nowego rekordu. Zwykle dzieje się tak z wartościami obliczonymi lub wartościami dodawanymi w wyzwalaczu INSERT
  • Czasami zapytania SQL są źle napisane i wolno wykonują się. Jeśli masz wolno działające zapytanie, uruchom śledzenie SQL, aby zobaczyć, co robi EF. Możliwe jest ponowne przetworzenie tego zapytania jako SP lub View. Nie zdarza się to jednak często.
  • Miałem kilka problemów z próbą utworzenia powiązania między tabelami, które nie mają zdefiniowanego klucza obcego w SQL Server. Zwykle dzieje się tak, ponieważ próbuję utworzyć 1:0-1relację, w której EF chce użyć1:0-*

Nie jestem jednak ekspertem w dziedzinie EF, więc prawdopodobnie przegapiłem kilka rzeczy. To tylko elementy, które znam w przeszłości, kiedy przechodziłem z wbudowanego SQL na Entity Framework. Cieszę się, że dokonałem zmiany, ale były czasy, kiedy naprawdę nienawidziłem EF z powodu jego dziwactw.

Rachel
źródło
7
+1 za szczegółową i uporządkowaną odpowiedź. „Wszystkie byty (tabele, widoki itp.) Potrzebują klucza podstawowego” brzmi raczej jak rozsądne ograniczenie niż oszustwo.
NoChance,
2
@EmmadKareem Jest to ok ograniczenie, jeśli masz kontrolę nad bazą danych, ale jeśli pracujesz z bazą danych innej firmy lub z widokami, może to być trochę denerwujące
Rachel
1
Po prostu spróbuj użyć EF w odłączonej aplikacji internetowej N-Tier - aktualizowanie encji w relacji i relacjach MM, hmmmmm, co za zabawa!
Vidar,
5
Jednostki @EmmadKareem naprawdę potrzebują klucza podstawowego o pojedynczej wartości - używanie kluczy kompozytowych jest koszmarem w EF. Jest to raczej oszustwo niż rozsądne ograniczenie.
Kirk Broadhurst,
1
Powiedziałbym, że bezpieczeństwo to kolejna kwestia. Wielu uważa, że ​​cały dostęp do bazy danych powinien przejść przez procedury składowane z rolami bazy danych powiązanymi z procs, aby określić, które logowania mogą wykonywać to, co przechowywane proc. Wyklucza to EF / LINQ do tworzenia zapytań. Użyłem EF, ale natknąłem się na klientów ( kaszel Microsoft), którzy mieli te wymagania bezpieczeństwa
Mick
12

Entity Framework to narzędzie zwiększające wydajność. Jeśli nie masz uzasadnionego powodu, aby tego nie robić (np. Korzystasz z SQL 2000 lub nie masz czasu, aby rozwinąć technologię), skorzystaj z najlepszych dostępnych narzędzi.

Biorąc to pod uwagę, uważam, że koncepcja jednostek bardzo dobrze przekłada się na model wzorca MVC. Chociaż relacja 1: 1 z modelami i tabelami jest złą praktyką, myślenie w kategoriach encji ma tendencję do tworzenia czystych projektów, łatwego do odczytania kodu (szczególnie w przypadku LINQ).

Entity Framework jest aktywnie wspierany przez Microsoft. Nikt nie ma magicznej kryształowej kuli, która by powiedziała „wsparcie potrwa X lat”. Nie widzę powodu, by sądzić, że Istota umrze w ciągu najbliższych 5 lat.

P.Brian.Mackey
źródło
3
LinqToSql zmarł dość szybko, więc naprawdę nie ma powodu, aby wierzyć w ten czy inny sposób, czy Entity Framework przetrwa. Warto wziąć pod uwagę nowy nacisk MS na Metro, ponieważ mogą rozważać przegląd wielu swoich ofert.
ocodo
3
Slomojo, być może masz inną definicję niż reszta świata słowa „Dead”. Ponieważ LinqToSql po prostu nie jest już aktywnie rozwijany. Nadal będziesz mógł z niego korzystać za 10-20 lat.
Boris Yankov,
4

Innym potencjalnym rozwiązaniem jest użycie alternatywnej biblioteki Entity Framework Library, która nie jest dostarczana z VS. Istnieje kilka dostępnych w Internecie.

Koncepcja szkieletu Entity / 3 layer istnieje już od jakiegoś czasu i współpracuje z kilkoma niestandardowymi bibliotekami, podobnie jak wielu innych programistów, zanim Microsoft wydał własną „oficjalną” strukturę.

Plusy

Korzystaj z frameworku Entity (DAL), nie blokując się ciągłymi zmianami bibliotek / frameworka Microsoft.

Dodanie funkcji do biblioteki, które być może nie są dostępne w istniejącej bibliotece oficjalnej, na przykład przy użyciu kilku marek dtabase.

Cons

Muszę wspierać bibliotekę lub narzędzia. Bardzo często jest używane narzędzie do kodowania generatora jednostek do generowania enitites.

umlcat
źródło
Uważam tę odpowiedź za bardzo mylącą. Istnieje tylko jeden Entity Framework (z dużymi literami), który produkuje Microsoft. Masz na myśli „użyj innego obiektu mapującego relacyjne obiekty”? Entity Framework nie jest terminem ogólnym - to nazwa ORM firmy Microsoft.
NickG
Chociaż istnieje „Microsoft Entity Framework”, koncepcja „Entity Framework” istnieje od kilku lat.
umlcat,
3

Musisz podjąć decyzję architektoniczną w oparciu o problem i istniejące rozwiązanie. Podobnie jak w przypadku każdej technologii, istnieją zalety i wady.

Osobiście zwykle używałbym frameworku encji do nowego programowania, ale nie przerabiałam działającego kodu. Otrzymujesz wtedy szybkość przyszłego usuwania, ale nie musisz inwestować dużo czasu na konwersję kodu. Wadą tego podejścia jest zmniejszenie spójności.

Tom Squires
źródło
3
+1 za odradzanie ponownego pisania działającego kodu.
NoChance,
2

W twojej sytuacji zdecydowanie użyłbym Entity Framework, przekonałem się, że działa dobrze z MVC.
Oto kilka prawdziwych powodów i wskazówek.

  • Linq jest przyjemny w użyciu, a opóźnione wykonanie jest również niezwykle przydatne.
  • Możesz wygenerować swoje modele (jednak przy korzystaniu z mvc polecam korzystasz z modeli widoków w połączeniu z modelami danych, to znacznie ułatwia walidację i wiązanie modeli, jeśli zastosujesz to podejście, użyj automappera, aby mapować zmiany z powrotem na twój model danych).

Jest jednak wiele rzeczy, których musisz się nauczyć o korzystaniu z ORM.

  • Co robi dla Ciebie kontekst (śledzenie encji)
  • Że kontekst powinien być wykorzystany jako jednostka pracy
  • Pamiętaj o rzeczach dotyczących współbieżności, EF może powiedzieć ci, kiedy twój obiekt jest nieaktualny, ale może to być trudne, jeśli chcesz poprawnie obsługiwać współbieżność w żądaniach (ponieważ musisz zachować znacznik czasu lub coś takiego).

Rzeczy do rozważenia

  • Wyzwalacze i ORM nie działają razem, zamiast tego używaj zdarzeń ORM.
  • Upewnij się, że wszystkie stoły mają klucze zastępcze.

Gorąco poleciłbym również pierwsze podejście do kodu, nawet jeśli masz już bazę danych.

  • Konwencje oznaczają, że nie trzeba ponownie generować mapowań ani klas podczas zmiany bazy danych.
  • Łatwiej jest umieścić walidację i inną logikę w modelach.
  • Możesz użyć generatora kodu, aby pomóc je zrobić, jeśli masz ogromną istniejącą bazę danych.
Daniel Little
źródło