Czy powinniśmy używać Entity Framework?

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.

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.

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.

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.

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.

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.