nHibernate a Entity Framework

Ostatnio natknąłem się na projekt napisany w ASP.NET MVC, który jako ORM zamiast korzystać z Entity Framework korzysta z nHibernate. Wg mnie jest to kiepski pomysł, ponieważ z tego co widzę to w nHibernate nie możliwości generowania migracji, co powoduje, że jak w projekcie pracuje wielu programistów to zarządzanie stanem bazy staje się uciążliwe. A co wy o tym sądzicie? Jest sens używać nHibernate czy tylko Entity Framework?

Nie znam nhibernate ale ef daje możliwości o których piszesz, myślę, że nhibernate ma podobne, ef to kupa i tyle w temacie...

Uważaj, bo grasuje tu taki jeden degenerat od nH...

A tak na serio, to:

https://stackify.com/entity-framework-core-nhibernate/

Najważniejszy argument za nH to chyba obsługiwane db.

Mikilll napisał(a):

Wg mnie jest to kiepski pomysł, ponieważ z tego co widzę to w nHibernate nie możliwości generowania migracji, co powoduje, że jak w projekcie pracuje wielu programistów to zarządzanie stanem bazy staje się uciążliwe.

Mnie się wydaje, że to jest problem albo z programistami albo z architekturą. Po pierwsze jest wbudowana metoda SchemaUpdate, po drugie doinstalowanie paczki obsługującej migracje z NuGeta chyba nie powinno być dużym utrudnieniem.

A co wy o tym sądzicie? Jest sens używać nHibernate czy tylko Entity Framework?

Nie no, pewnie, że lepiej używać tego ORMa, który nie ma cache drugiego poziomu, nie potrafi generować id, nie obsługuje różnych rodzajów kolekcji, nie daje żadnej kontroli nad generowanym SQL, nie pozwala na wysyłanie kilku zapytań w ramach jednego polecenia, i nie ma prawie żadnych możliwości rozszerzania. Tylko EF!

z tego co widzę to w nHibernate nie możliwości generowania migracji,

Może jesteś ślepy.

NH oferuje o wiele więcej, jeśli chodzi tworzenie zapytań i rozszerzanie jego funkcjonalności.
W EF zapis relacji związkach wiele do wiele to jakaś tragedia, musisz to wiązać identyfikatorami robić jakieś wspólne obiekty typu ProductCategory.

Niestety... choćbym nie wiem jak chwalił NH i jego przewagę nad EF to trzeba zdać sobie sprawę z faktu, iż na polskim rynku praktycznie nie istnieje. Ucząc się NH robi się z siebie swego rodzaju ekscentryka, który sunie pod prąd obecnych trendów. Trzeba zdać sobie z tego sprawę.

Dla tych co tak chwalą EF: spróbujcie zrobić RIGHT JOIN. ;-)

.AsNoTracking najbardziej użyteczne w EF!!! ;-) ;-)

somekind napisał(a):

Mikilll napisał(a):

Wg mnie jest to kiepski pomysł, ponieważ z tego co widzę to w nHibernate nie możliwości generowania migracji, co powoduje, że jak w projekcie pracuje wielu programistów to zarządzanie stanem bazy staje się uciążliwe.

Mnie się wydaje, że to jest problem albo z programistami albo z architekturą. Po pierwsze jest wbudowana metoda SchemaUpdate, po drugie doinstalowanie paczki obsługującej migracje z NuGeta chyba nie powinno być dużym utrudnieniem.

W Entity Framework jeżeli inny programista zmieni stan bazy i wygeneruje migracje to drugi programista może wykonać w konsoli "Update-Database" i zaaktualizować swój stan bazy. Czy serio nHibernate daje taką możliwośc? Szukałem trochę w Internecie i nie znalazłem za bardzo żadnego popularnego toola do nHibernate, który by ogarniał takie rzeczy. W Entity Framework jest to od razu wbudowane.

A po co wam te ORM'y, zamiast opierać się na lazy loading lepiej jest napisać wyspecyfikowane zapytanie. Jeśli potrzebujesz cache pierwszego poziomu to prawdopodobnie robisz coś dziwnego, bo jak wyjaśnić odpytywanie dwa razy o to samo w jednym lifecycle sesji. Cache drugiego poziomu i tak nikt nie używa a przecież silnik bazodanowy ma wbudowany sam w sobie cache. Prawdziwe hardcore piszą stringi do sql'a i wszystko ręcznie mapują.

Mikilll napisał(a):

W Entity Framework jeżeli inny programista zmieni stan bazy i wygeneruje migracje to drugi programista może wykonać w konsoli "Update-Database" i zaaktualizować swój stan bazy. Czy serio nHibernate daje taką możliwośc? Szukałem trochę w Internecie i nie znalazłem za bardzo żadnego popularnego toola do nHibernate, który by ogarniał takie rzeczy. W Entity Framework jest to od razu wbudowane.

SchemaUpdate też jest wbudowane w NHibernate. To działa inaczej niż migracje w EF (nie masz wielu "etapów"), ale jak dla mnie efekt jest ten sam.

Przerabialem już w życiu kilka technologii, najlepsza to był specjalizowany język i dedykowana do niego baza ( OpenEdge). W związku z tym każdemu jestem w stanie złożyć ukłon jeśli pozbawi mnie możliwości pisania stringów SQL do bazy!!! ORMy jednak sobie z tym radzą?! Mechanizm aktualizacji bazy danych w EF załatwione kompleksowo przez wbudowane mechanizmy. Jest parę tematów z których można skorzystać w EF i daje to jakiś pozytyw, ale nie jest to wspaniałe narzędzie i to chyba na tyle.

somekind napisał(a):

Mikilll napisał(a):

W Entity Framework jeżeli inny programista zmieni stan bazy i wygeneruje migracje to drugi programista może wykonać w konsoli "Update-Database" i zaaktualizować swój stan bazy. Czy serio nHibernate daje taką możliwośc? Szukałem trochę w Internecie i nie znalazłem za bardzo żadnego popularnego toola do nHibernate, który by ogarniał takie rzeczy. W Entity Framework jest to od razu wbudowane.

SchemaUpdate też jest wbudowane w NHibernate. To działa inaczej niż migracje w EF (nie masz wielu "etapów"), ale jak dla mnie efekt jest ten sam.

1. Gdzie jest jakaś oficjalna dokumentacja do SchemaUpdate w nHibernate, bo naprawdę nie mogę nic znaleźć sensownego w Internecie?
2. Czy działa to tak jak w Entity Framework, że wpisuje się komendy w konsoli?

Czy działa to tak jak w Entity Framework, że wpisuje się komendy w konsoli?

Odnoszę wrażenie, że bardzo chciałbyś by NH był jak EF. Otóż tak nie jest. Są to dwa, całkowicie różne konceptualnie ORM'y.

W NH niczego nie wpisuje się w konsoli. Przy odpowiedniej konfiguracji aktualizacja bazy na podstawie encji przebiega automatycznie i nie trzeba bawić się w konsolę.

Wersjonowanie aplikacji można ładnie zapiąć w metody, które po prostu propagują zmiany, a sama baza aktualizuje się automagicznie.

grzesiek51114 napisał(a):

Czy działa to tak jak w Entity Framework, że wpisuje się komendy w konsoli?

Odnoszę wrażenie, że bardzo chciałbyś by NH był jak EF. Otóż tak nie jest. Są to dwa, całkowicie różne konceptualnie ORM'y.

W NH niczego nie wpisuje się w konsoli. Przy odpowiedniej konfiguracji aktualizacja bazy na podstawie encji przebiega automatycznie i nie trzeba bawić się w konsolę.

Wersjonowanie aplikacji można ładnie zapiąć w metody, które po prostu propagują zmiany, a sama baza aktualizuje się automagicznie.

Automatycznie? Czyli co jak np. kolega zmieni schemat bazy, a ja przełącze się na jego commita w Gicie?

Skąd mam wiedzieć? :) Nie pracowałem grupowo w projekcie z NH to nie wiem, a i samego ORM'a widziałem ostatnio może... 7mieś. temu. :)

Pamiętam za to, że takie rzeczy ustawia się podczas konfigurowania SessionFactory, zwyczajnie dopisując SchemaUpdate do łańcuszka metod. Czy jakoś tak, 7mieś. przerwy od ORM'ów robi swoje.

Mikilll napisał(a):

Automatycznie? Czyli co jak np. kolega zmieni schemat bazy, a ja przełącze się na jego commita w Gicie?

To odpalisz konsolową apkę, którą masz w solucji, a która wywoła SchemaUpdate na konfiguracji NH ze zmianami wprowadzonymi przez kolegę.
A jak nie masz tej apki w solucji, to należy wrócić do mojego pierwszego posta - jest jakiś problem z architekturą.

Ja mam wrażenie, że Ty pierwszy raz w życiu zobaczyłeś tramwaj i twierdzisz, że to nie może jechać, bo nie ma gdzie wlać benzyny.