Ostatnio w pracy starsi programiści zastanawiali się, którego orma uzyc w nowym projekcie: entity frameworka czy nhibernate. Wybor padl na entity framework, a o wyborze zdecydowal fakt, ze.......... podobno nhibernate jest dostepny w jakiejs starej wersji i nie jest rozwijany, zdziwilo mnie to wiec zajrzalem do wikipedii i z tego co widze to nhibernate jest rozwijany - czy sie myle?
0
1
Oczywiście, że jest rozwijany, niedługo ma być wersja 4.0. Jest to na dodatek chyba najbardziej popularny projekt OS typu ORM w świecie .NET.
Skąd Ty wziąłeś tych starszych programistów? :P
0
Dzieki za info, to ja nie wiem co im odbilo, ze powiedzieli, ze nie jest rozwijany.... lol
2
Faktycznie słyszałem historię, że był pewien kryzys (chyba chodziło o rozłam między ekipą nhibernate a fluent-nhibernate, chociaż nie znam szczegółów) i w pewnym momencie główny autor projektu nhibernate ogłosił koniec dalszego rozwoju. Ale potem się jednak dogadali, jak widać projekt ma się dobrze.
4
Przypadkiem trafiłem na taki badziewny artykuł: http://www.devbridge.com/articles/entity-framework-6-vs-nhibernate-4/ pod którym można znaleźć ciekawe komentarze.
Jeden z nich chyba wyjaśnia całą sytuację:
EF fanboys are pleased because EF commits increase while NH decrease.
Know why that happens?
- EF doesn't have even half of NH features and it has a lot more to get to catch;
- NH is mature, not much to be done, only some tunnings and stuff. Why would you bother commiting 100 pull requests for something that doesn't require that much of change?
Zaś pierwszy chyba dostatecznie opisuje, czemu EF jest do kitu:
- NH has 10+ id generator strategies (IDENTITY, sequence, HiLo, manual, increment, several GUIDs, etc), EF only has manual or SQL Server's IDENTITY;
- NH has lazy property support (note: not entities, this is for string, XML, etc properties), EF doesn't;
- NH has second level cache support (and, believe me, enterprise developers are using it) and EF doesn't;
- NH has support for custom types, even complex, with "virtual" properties, which includes querying for these virtual properties, EF doesn't;
- NH has formula properties, which can be any SQL, EF doesn't;
- NH has automatic filters for entities and collections, EF doesn't;
- NH supports collections of primitive types (strings, integers, etc) as well as components (complex types without identity), EF doesn't;
- NH supports 6 kinds of collections (list, set, bag, map, array, id array), EF only supports one;
- NH includes a proxy generator that can be used to customize the generated proxies, EF doesn't allow that;
- NH has 3 mapping options (.HBM.XML, by code, by attributes) and EF only two (by attributes, by code);
- NH allows query and insertion batching (this is because EF only really supports IDENTITY keys), EF doesn't;
- NH has several optimistic control strategies (column on the db, including Oracle's ORA_ROWSCN, timestamp, integer version, all, dirty columns), EF only supports SQL Server' TIMESTAMP or all.
0
NHibernate possysa z prostego powoduje - nie jest ze stajni Microsoftu :<
4
@ne0,
generatory ID - zwykle jakoś chcemy identyfikować encje zapisywane do bazy, w tym celu zakładamy klucz główny na którejś z kolumn w tabeli. Pozostaje problem, skąd wziąć wartość tego ID? Można kazać bazie generować wartości dla kluczy głównych, ale to podejście jest bez sensu, gdy stosujemy ORM, bo po utworzeniu nowego obiektu i zapisaniu go, musimy dodatkowo odpytać bazę o ID tego obiektu. Ponadto, takie podejście sprawia, że nie możemy wygenerować po stronie aplikacji całego grafu powiązanych ze sobą obiektów i zapisać go do bazy "na raz", musimy zapisywać każdy obiekt po kolei, pobierać jego ID, i przypisywać je do powiązanych obiektów.
NHibernate pozwala na generowanie ID po stronie aplikacji na wiele sposobów, tak aby baza nie musiała się tym zajmować, a z drugiej strony, aby wartości generowane programowo były ciągle unikalne. Pozwala nawet na generowanie ID typu GUID, które nie rozwalają indeksów w bazie.
typy kolekcji - nie chodzi o typy powiązań między relacjami, ale o typy kolekcji. W EF kolekcja musi być typu DbSet<T>. NH pozwala na list (uporządkowana, pozwala na duplikaty), set (nieuporządkowany, tylko unikalne wartości), bag (nieuporządkowany, duplikaty dozwolone), map (słownik klucz-wartość), i inne.
cache 2 poziomu - w odróżnieniu od cache 1 poziomu, istnieje na poziomie SessionFactory, więc przez cały czas życia aplikacji. Dane do niego raz wczytane są przechowywane do końca, co zmniejsza liczbę odczytów z bazy danych. Przydaje się do przechowywania danych rzadko zmienianych, np. stawek VAT, struktury administracyjnej kraju, itd.
1
somekind napisał(a):
takie podejście sprawia, że nie możemy wygenerować po stronie aplikacji całego grafu powiązanych ze sobą obiektów i zapisać go do bazy "na raz", musimy zapisywać każdy obiekt po kolei, pobierać jego ID, i przypisywać je do powiązanych obiektów
EF potrafi coś takiego - przy zapisywaniu obiektu razem z nim zapisywane są wszystkie nowe/zmienione obiekty połączone z "głównym" obiektem kluczami obcymi. Co prawda nie przyglądałem się wykonywanemu w takim przypadku sql (bo może jakiś głąb zaimplementował to tak, jak to opisałeś), ale z mojej perspektywy jest to mało istotne. SaveChanges() zapisuje całe drzewko, amen.
0
takie podejście sprawia, że nie możemy wygenerować po stronie aplikacji całego grafu powiązanych ze sobą obiektów i zapisać go do bazy "na raz", musimy zapisywać każdy obiekt po kolei, pobierać jego ID, i przypisywać je do powiązanych obiektów
Teraz to żeś pojechał.
0
ŁF napisał(a):
EF potrafi coś takiego - przy zapisywaniu obiektu razem z nim zapisywane są wszystkie nowe/zmienione obiekty połączone z "głównym" obiektem kluczami obcymi. Co prawda nie przyglądałem się wykonywanemu w takim przypadku sql (bo może jakiś głąb zaimplementował to tak, jak to opisałeś), ale z mojej perspektywy jest to mało istotne. SaveChanges() zapisuje całe drzewko, amen.
Ja nie twierdzę, że EF radzi sobie z zapisaniem grafu obiektów, bo ja w ogóle nie o tym pisałem. Całość mojej wypowiedzi brzmiała:
Można kazać bazie generować wartości dla kluczy głównych, ale to podejście jest bez sensu, gdy stosujemy ORM, bo po utworzeniu nowego obiektu i zapisaniu go, musimy dodatkowo odpytać bazę o ID tego obiektu. Ponadto, takie podejście sprawia, że nie możemy wygenerować po stronie aplikacji całego grafu powiązanych ze sobą obiektów i zapisać go do bazy "na raz", musimy zapisywać każdy obiekt po kolei, pobierać jego ID, i przypisywać je do powiązanych obiektów.
Chodziło mi o współpracę bazy z aplikacją - jeśli ID są generowane przez bazę, to nie możemy ich wygenerować po stronie aplikacji, lecz musimy po każdym insercie pobrać id wstawionego rekordu, i przypisać go do powiązanego obiektu w grafie. Nie ma znaczenia, czy robimy to ręcznie, czy ORM zrobi to sam - to po prostu nikomu niepotrzebna robota, którą można pominąć generując id po stronie aplikacji.
franck napisał(a):
Teraz to żeś pojechał.
Gdyż?