Entity Framework VS LINQ to SQL VS ADO.NET z procedurami składowanymi?

Question

Entity Framework VS LINQ to SQL VS ADO.NET z procedurami składowanymi?

Jak oceniłbyś każdy z nich w kategoriach:

Wydajność
szybkość rozwoju
czysty, intuicyjny, łatwy w utrzymaniu kod
elastyczność
ogólnie

Lubię mój SQL i tak zawsze byłem zagorzałym fanem ADO.NET i procedur przechowywanych, ale ostatnio miałem zabawę z Linq do SQL i był zdumiony tym, jak szybko pisałem moją warstwę DataAccess i zdecydowałem się spędzić trochę czasu naprawdę rozumiejąc albo Linq do SQL, albo EF... czy ani jedno, ani drugie?

Chcę tylko sprawdzić, czy żadna z tych technologii nie ma wielkiej wady, która uczyniłaby mój czas badań bezużytecznym. Np. wydajność jest straszna, jest fajna dla prostych aplikacji, ale może tylko zabrać cię do tej pory.

Aktualizacja: Czy możesz skoncentrować się na EF VS L2S VS SPs zamiast ORM VS SPs. Interesuje mnie głównie EF VS L2S. ale jestem chętny, aby je porównać z przechowywanymi procami, ponieważ zwykły SQl jest czymś, o czym wiem dużo.

400

sql linq-to-sql entity-framework ado.net linq-to-entities

Author: BritishDeveloper, 2010-04-23

Source

4 answers

Procedury przechowywane:

(++)

duża elastyczność
Pełna kontrola nad SQL
najwyższa dostępna wydajność

(--)

wymaga znajomości SQL
procedury przechowywane są poza kontrolą źródła
znaczna ilość "powtarzania się" przy określaniu tych samych nazw tabel i pól. Duża szansa na złamanie aplikacji po zmianie nazwy jednostki DB i pominięciu niektórych odniesień do niej gdzieś.
powolny rozwój

ORM:

(+)

szybki rozwój
kod dostępu do danych teraz pod kontrolą źródła

(-)

wydajność może być gorsza
Brak lub niewielka kontrola nad SQL ORM produkuje (może być nieefektywne lub gorzej buggy). Może trzeba interweniować i zastąpić go niestandardowe procedury przechowywane. To spowoduje bałagan w Twoim kodzie (niektóre LINQ w kodzie, niektóre SQL w kodzie i / lub w DB poza kontrolą źródła).
jak każda abstrakcja może produkować" wysokiego poziomu " programistów nie mających pojęcia, jak to działa pod maską

Ogólny kompromis polega na tym, że masz dużą elastyczność i tracisz dużo czasu, a nie ograniczasz się do tego, co możesz zrobić, ale robisz to bardzo szybko.

Nie ma ogólnej odpowiedzi na to pytanie. To kwestia święte wojny. Zależy również od projektu pod ręką i Twoich potrzeb. Wybierz to, co najlepsze dla Ciebie.

86

Author: ,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2010-04-23 11:52:45

Twoje pytanie to w zasadzie O / RM vs ręczne pisanie SQL

Używając ORM czy zwykłego SQL?

Spójrz na inne rozwiązania O / RM, L2S nie jest jedynym (NHibernate, ActiveRecord)

Http://en.wikipedia.org/wiki/List_of_object-relational_mapping_software

Aby odpowiedzieć na konkretne pytania:

jest to zwykle znacznie szybsze korzystanie z O / RM po podgrzaniu procesu
kod jest zwykle znacznie bardziej schludny i łatwiejszy do utrzymania
prosty SQL oczywiście zapewni Ci większą elastyczność, ale większość O / RM może wykonać wszystkie, oprócz najbardziej skomplikowanych zapytań
ogólnie proponowałbym iść z O / RM, utrata elastyczności jest zaniedbywalna

18

Author: BlackICE,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2017-05-23 12:26:32

LINQ-to-SQL jest niezwykłym kawałkiem technologii, który jest bardzo prosty w użyciu i ogólnie generuje bardzo dobre zapytania do zaplecza. LINQ-to-EF miał go zastąpić, ale historycznie był bardzo nieporęczny w użyciu i generował znacznie gorszy SQL. Nie znam obecnego stanu rzeczy, ale Microsoft obiecał przenieść wszystkie zalety L2S do L2EF, więc może teraz jest już lepiej.

Osobiście mam namiętną niechęć do narzędzi ORM (zobacz moją diatrybę TUTAJ dla szczegółów), a więc nie widzę powodu, aby faworyzować L2EF, ponieważ L2S daje mi wszystko, czego kiedykolwiek oczekuję od warstwy dostępu do danych. W rzeczywistości nawet uważam, że funkcje L2S, takie jak ręcznie wykonane mapowania i modelowanie dziedziczenia dodają zupełnie niepotrzebnej złożoności. Ale to tylko ja. ;-)

13

Author: Marcelo Cantos,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2017-05-23 12:10:44

score 414 · Accepted Answer

Po pierwsze, jeśli zaczynasz nowy projekt, przejdź z Entity Framework ("EF") - teraz generuje znacznie lepszy SQL (bardziej jak LINQ do SQL robi) i jest łatwiejszy w utrzymaniu i bardziej wydajny niż Linq do SQL ("L2S"). Od wydania. NET 4.0 uważam Linq do SQL za przestarzałą technologię. Państwa członkowskie są bardzo otwarte w kwestii dalszego rozwoju L2S.

1) Wydajność

Trudno odpowiedzieć. Dla większości operacji z jednym podmiotem (CRUD ) znajdziesz prawie równoważną wydajność dla wszystkich trzech technologii. Musisz wiedzieć, jak działają EF i Linq to SQL, aby w pełni je wykorzystać. W przypadku dużych operacji, takich jak zapytania ankietowe, możesz chcieć, aby EF/L2S "skompilował" zapytanie encji, tak aby framework nie musiał stale regenerować SQL lub możesz napotkać problemy ze skalowalnością. (zobacz edycje)

Dla masowych aktualizacji, w których aktualizujesz ogromne ilości danych, surowy SQL lub przechowywany procedura zawsze będzie działać lepiej niż rozwiązanie ORM, ponieważ nie musisz przesyłać danych przez przewód do ORM, aby wykonać aktualizacje.

2) szybkość rozwoju

W większości scenariuszy, EF zdmuchnie nagie SQL / przechowywane proc jeśli chodzi o szybkość rozwoju. Projektant EF może zaktualizować model z bazy danych w miarę zmian (na żądanie), dzięki czemu nie występują problemy z synchronizacją między kodem obiektowym a kodem bazy danych. Jedyny czas, w którym nie rozważałbym korzystania z ORM, jest wtedy, gdy robisz aplikację typu raportowanie / pulpit nawigacyjny, w której nie robisz żadnej aktualizacji, lub gdy tworzysz aplikację, aby wykonać operacje konserwacji surowych danych w bazie danych.

3) Neat / Maintainable code

Ręce w dół, EF bije SQL / sprocks. Ponieważ twoje relacje są modelowane, połączenia w kodzie są stosunkowo rzadkie. Relacje podmiotów są dla czytelnika niemal oczywiste dla większości zapytania. Nie ma nic gorszego niż przechodzenie od warstwy do warstwy debugowania lub przez wiele warstw SQL/warstwy średniej, aby zrozumieć, co naprawdę dzieje się z danymi. EF wprowadza model danych do kodu w bardzo wydajny sposób.

4) elastyczność

Przechowywane proc i surowy SQL są bardziej "elastyczne". Możesz wykorzystać sprocks i SQL do generowania szybszych zapytań dla konkretnego przypadku, a także możesz wykorzystać natywną funkcjonalność DB łatwiej niż możesz z i ORM.

5) ogólnie

Nie daj się wciągnąć w fałszywą dychotomię wyboru ORM vs korzystanie z procedur przechowywanych. Możesz używać obu w tej samej aplikacji i prawdopodobnie powinieneś. Duże operacje masowe powinny być wykonywane w procedurach przechowywanych lub SQL (które mogą być wywoływane przez EF), a EF powinny być używane do operacji CRUD i większości potrzeb średniego poziomu. Być może zdecydowałbyś się użyć SQL do pisania raportów. Chyba Morał z tej historii jest tak jak zawsze. Użyj odpowiedniego narzędzia do pracy. Ale chuda jest, EF jest bardzo dobry w dzisiejszych czasach (od.NET 4.0). Poświęć trochę czasu na dogłębne czytanie i zrozumienie go w czasie rzeczywistym, a z łatwością stworzysz niesamowite, wysokowydajne aplikacje.

EDIT: EF 5 nieco upraszcza tę część za pomocą Auto-skompilowanych zapytań LINQ , ale w przypadku naprawdę głośnych rzeczy, na pewno będziesz musiał przetestować i przeanalizować to, co najlepiej pasuje do Ciebie w prawdziwym świecie.