NHibernate vs. EF 4.1+

Question

Staram się decydować o zaletach i wadach 2 ORM głównie w tym obszarze.

1. Kompatybilność z SQL Server 2008 R2 & 2012.
   • Jest to bardzo ważne, ponieważ po prostu nie mają środków do debugowania słabe wsparcie istniejących technologii MS stosu.
   • Również planowanie z wyprzedzeniem od 2012 roku jest prawie niemożliwe i planuje się przeprowadzić migrację do niego.
2. Wsparcie dla .NET 4.0 i 4.5 (nadchodzący)
   • Ponownie bardzo ważne dla prawie tego samego powodu powyżej.
3. Obsługa transakcji i wskazówki dotyczące tabel, np. forcecan forceseek, czytaj bez zaproszenia.
   • Wiele razy optymalizator zapytań wykonuje swoją pracę dobrze, innym razem chcę elastyczność, aby powiedzieć, co robić.
4. Wsparcie dla rozmowy, śledzenie siebie przywiązują & odłączyć
   • Jest to nieco podstawowe. Nienawidzę, aby sesja była otwarta przez dłuższy czas. Zwłaszcza w środowisku przetwarzania rozproszonego/środowiska sieciowego.
5. Możliwość obsługi kodu rozwijającego się, tworzenia i aktualizowania schematu bez niszczenia danych.
   • Wydaje się, że EF 4.1 jest chciany pod tym względem, choć 4.3 jest lepszy i lepiej związany. Również polubienie adnotacji danych jest lepsze niż oddzielne klasy mapowania w NH. Powodem jest to, że chcę móc wysłać klasę, a stamtąd można stworzyć model trwałości bez rozszerzania metody dla klas mapowania.
6. Wsparcie IRepository wzór
7. Wsparcie dla LINQ
   • Nieco przywiązany do (6) powyżej Chcę naprawdę dobre wsparcie dla LINQ. Nie chcę programistom syf wokół z realizacji niższego poziomu i zaczyna się przykleiła się do jednego konkretnego ORM
8. Wydajność
9. wsparcia dla operacji CRUD luzem, bez konieczności ładowania danych w warstwie aplikacji. Na przykład. Chcę zwiększyć wszystkie wiersze w kolumnie konkretnej tabeli o 1. Nie chcę ładować tego do pamięci i zwiększać wiersze jeden po drugim. To byłoby szalone z powodu tak prostej operacji. Linq2Sql kiedyś miał Magiqa do obsługi tego typu rzeczy, co mają NH i EF?
10. Buforowanie, szybkie ładowanie, opóźnione ładowanie, właściwości nawigacyjne.
    • Powiem szczerze, nienawidzę tych rzeczy, gdy robię to bezwarunkowo. Powód, dla którego trudno odróżnić to, co jest zbuforowane, nieaktualne od tego, co nowe. W EF zwykle zrzucam wszystkie właściwości nawigacji, ponieważ nie chcę, aby te właściwości były ładowane z top 5, ponieważ tego właśnie potrzebuje obecna operacja, ale w dalszej części strumienia inny programista próbuje wykonać obliczenie, które będzie niedokładne.
    • Tak więc moja polityka osobista - wszystkie SOA będą bezpaństwowcami, chyba że istnieje ku temu uzasadniony powód. Jeśli potrzebujesz danych odniesienia, pozbądź się go. Będzie wolniejszy, ale kod będzie bardziej czytelny i elastyczny.
    • Podobnie do buforowania. Jest wystarczająco złożony, ponieważ jest w środowisku rozproszonym, chcę, aby wszystkie buforowanie było bardzo bardzo wyraźne. Jeśli programista chce kodować pamięć podręczną, powinien to zrobić, a nie kodować do ORM i sprawić, aby wyglądał tak, jakby wyciągał świeże dane z trwałości, gdy w rzeczywistości uzyskuje on nieaktualne dane.
    • Teraz pytanie brzmi, czy NHibernate ma jakąkolwiek koncepcję/abstrakcję, która powodowałaby, że buforowanie, przyspieszone/leniwe ładowanie było znacznie bardziej wyraźne niż obecnie dostępne w EF. W tym przypadku nie dbam o łatwość rozwoju, bardziej zależy mi na przejrzystości i jasności.

Również nie obchodzi mnie dużo dla OSS vs. propietary argument. Zespół nie może sobie pozwolić na zerknięcie pod kaptur i zaczepianie się za pomocą kodu innych ludzi. Dbam więcej o kąt "po prostu działa" niż cokolwiek innego.

Answer 1

Można użyć bltoolkit;) ->http://www.bltoolkit.net/Doc.Linq.ashx

Wystarczy wziąć 2 minut na przeczytanie tego ->http://www.bltoolkit.net/Doc.LinqModel.ashx

Ale w krótkich

• bardzo dobre wsparcie LINQ
• operacji DML (nr 9)
• świetna obsługa performace/bulk
• wielki generowane Sql
• wsparcie enum ;-)
• nie leniwy załadunku/śledzenie jednostka/specjalne buforowanie magia, teraz te rzeczy, które zwykle powodują problemy
• żadnych magicznych właściwości -> mniej abstrakcji -> mniej przecieków -> mniej kłopotów -> mniejszy krzywa uczenia

btw to nie nr 3, ma atrybuty TableFunction & TableExpression wspierać wycenione tabela UDF, podpowiedzi i inne dekoracje wokół stołu. Więc można napisać własne rozszerzenie metod do wykorzystania w LINQ sprawozdaniach np

[TableExpression("{0} {1} WITH (TABLOCK)")] 
public Table<T> WithTabLock<T>() 
    where T : class 
{ 
    return _ctx.GetTable<T>(this, ((MethodInfo)(MethodBase.GetCurrentMethod())).MakeGenericMethod(typeof(T))); 
} 

a następnie

using (var db = new TestDbManager()) 
{ 
    var q = 
     from p in new Model.Functions(db).WithTabLock<Parent>() 
     select p; 

    q.ToList(); 
} 

Sample operacji DML

db.Employee 
    .Where(e => e.Title == "Spectre") 
    .Set(e => e.Title, "Commander") 
    .Update(); 

Answer 2

Nie chcesz żadnego z nich. Nie będziesz w stanie określać arbitralnych wskazówek dotyczących stołów i nie będzie on mógł być tak elastyczny, jak byś tego chciał.

Jeśli wszystkie te wymagania są wymagane, na planecie nie ma ORM, który je spełni.

EDIT:

oparciu o komentarz. nHibernate da ci największą moc, ale kosztem większej złożoności podczas konfigurowania twojego modelu. Jest kilka narzędzi, które mogą pomóc, ale każdy ma swoje plusy i minusy.

EF jest łatwiejszy w konfiguracji i użyciu, ale mniej wydajny. nHibernate jest odwrotnie. Musisz wybrać między mocą a złożonością.

BTW, w odniesieniu do operacji masowych, a co nie, można po prostu wydać SQL bezpośrednio z frameworka dla takich operacji. Lub zadzwoń do zapisanego proc.

Answer 3

Przede wszystkim wolę NHibernate pod różnymi względami. Entity Framework tęskni za czymś również w wersji 5.0.

1. jest bardzo łatwo dodać nowy typ w NHibernate, więc jeśli SQL Server 2012 oferuje nowe typy można zaimplementować względną dialekt/provider, ale społeczność zawsze działa
2. wiem, że zespół NH jest praca nad wsparciem FW 4.5, EF supports to z 5.0
3. Korzystanie NH można zrobić wszystko, co chcesz
4. NH obsługuje metodę łączą się ponownie dołączyć podmiot, EF również
5. EF nie obsługuje konwencji nazewnictwa, NH robi, ja też pisanie auto mapper oparty na DataAnnotations, here link do starej wersji, poczekaj 2 tygodnie na nowy
6. Używając NH lub EF możesz zaimplementować Warstwę Danych z wzorami Repozytorium i Jednostki Pracy, muszę również wydać ten pakiet na NuGet
7. EF w pełni obsługuje LINQ, NH nie, ale można załatać za pomocą rozszerzenia point
8. Myślę, że wyniki są na tym samym poziomie, NH lepiej obsługuje pamięć podręczną poziomu drugiego, więc łatwo jest zapobiec trafieniom w bazę danych
9. NH ma ulepszone porcjowanie support, nie wiem o EF (specjalnie 5.0)
10. NH ma lepszą realizację punktów rozszerzeń, więc proxy/cache/rejestrowania są potężne niż EF, ale w EF można napisać wrapper, aby uzyskać to, czego potrzebujesz

na koniec, z NH jest łatwiejsze do wdrożenia wzoru DDD, ponieważ mapowanie jest bardziej elastyczne.

Answer 4

Wystarczy dodać do innych odpowiedzi ...

Ricardo Peres napisał bardzo dobry, bezstronnej porównanie NHibernate i Entity Framework kilka dni temu. To może ci pomóc w badaniach.

Można go znaleźć tutaj: http://weblogs.asp.net/ricardoperes/archive/2012/06/07/differences-between-nhibernate-and-entity-framework.aspx

Answer 5

Chociaż pisałem o niektórych z tych kwestii w another question, myślę, że warto odpowiedzieć na to jeden punkt po punkcie.

1. Oba są kompatybilne ze wszystkimi wersjami SQL Server
2. Oba są kompatybilne z .NET 4.x NH nadal kieruje się na 3.5, co nie jest problemem.
3. Oba mają obsługę transakcji. Żadne z nich nie obsługuje podpowiedzi do zapytań w natywnych językach zapytań, ale oba umożliwiają korzystanie z SQL.
4. Obie pozwalają na dołączanie odłączonych elementów. Osobiście nie sądzę, że jest to dobra praktyka (preferuję przekazywanie DTO dookoła)
5. Migracja schematów jest bardziej dojrzała i elastyczna w EF. Mapowanie jest lepsze, lepsze w NH. Posiada wsparcie dla mapowania z atrybutami, który jest o wiele mocniejszy niż odpowiednik EF, który szybko znajdziesz nie obsługuje nawet podstawowych rzeczy (jak precyzowanie dokładności pola dziesiętnego).
6. Możesz zaimplementować swoje repozytorium na wierzchu albo jeden.
7. Oba obsługują LINQ. EF obsługuje szerszy zakres zapytań, czasami kosztem generowania niezwykle nieefektywnych. Nie powinieneś ignorować swoich praktyk rozwojowych; każda metoda zapytania ma swoje zalety, a dobry programista powinien znać opcje.
8. Wydajność jest zwykle lepsza w przypadku NH ze względu na elastyczność odwzorowania i obsługę grupowania, buforowania i instrukcji DML.
9. EF nie obsługuje operacji zbiorczych (DML).NH robi, za pomocą INSERT/UPDATE/DELETE, które są bardzo podobne do tych, SQL, ale z modelu obiektów (na przykład, można określić warunki korzystania dot składni zamiast wyraźny sprzężeń)
10. • EF nie obsługuje buforowanie, kropka. Istnieje kilka nieobsługiwanych próbek, które nie są gotowe do produkcji. Całe buforowanie w NHibernate jest jawne (określasz, które encje, kolekcje i zapytania chcesz buforować, jak długo, itd.). Obsługuje rozproszone pamięci podręczne, takie jak memcached, więc może zająć się również nieaktualnymi danymi z pamięci podręcznej.
    • Obie pozwalają na jawne i chętne ładowanie referencji i kolekcji. NH ma, moim zdaniem, lepszy projekt proxy, który nie zanieczyszcza twojego modelu za pomocą FK (jest to długi temat, możesz wysłać pytanie uzupełniające, jeśli chcesz). I jak zwykle, masz więcej elastyczności podczas określania sposobu ładowania każdego związku.

W skrócie: NH jest bardziej elastyczny i poprawy jego efektywności, ręce w dół. EF ma lepszą obsługę migracji, nieco łatwiejszą krzywa uczenia się i bardziej kompletny dostawca LINQ.