NHibernate lub LINQ do SQL [zamknięty]

Jeśli rozpoczynasz nowy projekt, czego byś użył dla swojego ORM NHibernate lub LINQ i dlaczego. Jakie są plusy i minusy każdego.

Edit: LINQ to SQL not only LINQ (thanks @Jon Limjap)

Author: Gareth Jenkins, 2008-09-10
Source

6 answers

Zadałem sobie bardzo podobne pytanie z tym, że zamiast NHibernate myślałem o WilsonORM, który uważam za całkiem ładny.

Wydaje mi się, że istnieje wiele istotnych różnic.

LINQ:

  • nie jest kompletnym narzędziem ORM (można się tam dostać z kilkoma dodatkowymi bibliotekami, takimi jak najnowszy Framework Entity - osobiście uważam, że architektura tej najnowszej technologii z MS ma około 10 lat w porównaniu z innymi ORM Framework)
  • jest przede wszystkim zapytaniem "języka" wspierającym intellisense (kompilator sprawdzi składnię twojego zapytania)
  • jest używany głównie z Microsoft SQL Server
  • jest zamkniętym źródłem

NHibernate:

  • is ORM tool
  • ma dość ograniczony język zapytań bez intellisense
    • Może być używany z prawie każdym DBMS, dla którego masz dostawcę DB
  • jest open source

To naprawdę zależy. Jeśli rozwiniesz bogatą (Windows) aplikacja desktopowa, gdzie trzeba konstruować obiekty, pracować z nimi i na koniec utrzymywać ich zmiany, wtedy polecam Framework ORM jak NHibernate.

Jeśli tworzysz aplikację internetową, która zazwyczaj odpytywa Dane i tylko sporadycznie zapisuje niektóre dane z powrotem do bazy danych, to polecam dobry język zapytań, taki jak Linq.

Więc jak zawsze, to zależy. :-)

 13
Author: David Pokluda,
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
2008-09-10 04:45:41

Errr... jest LINQ dla NHibernate.

Być może chodzi Ci o to, czego użyć:

  • LINQ do SQL
  • NHibernate

Wolę NHibernate.

LINQ do SQL jest dość lekki, ale jest nieco bardziej ściśle powiązany ze strukturą danych, w przeciwieństwie do NHibernate, który jest dość elastyczny pod względem typów definicji obiektów, które można odwzorować na struktury tabel.

Oczywiście, że nie znaczy, że LINQ do SQL nie ma zastosowania: ta strona używa go. Uważam, że bardzo przydatne jest uruchomienie i uruchomienie w małych aplikacjach, w których schemat bazy danych nie jest tak ogromny.

 10
Author: Jon Limjap,
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
2008-09-10 04:41:36

Start z NHibernate to zły pomysł. Pokazuje dobrą wydajność tylko z umiejętnymi ustawieniami. Spróbuj użyć EFv4 dla dużych projektów i L2S (może produktów 3rd-part) dla małych i średnich rozmiarów. Produkty te są wygodniejsze i bardziej elastyczne niż NHibernate i umożliwiają szybkie rozpoczęcie pracy.

 3
Author: JackD,
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-12-02 16:21:50

Nie jest kompletna lista

LinqToSQL Pro:

  • lepsza obsługa narzędzi
  • dobry dostawca linq
  • łatwy początek gdy db-schema = = klasy -

Con:

  • nie elastyczny (czyli db-schema != classes)
  • obsługuje tylko MS SQL Server
  • Brak kaskadowania (Zapisz, update ... doesnt cascade to referred objects)

NHibernate Pro:

  • Wiele rdbms obsługiwane ootb
  • bogaty w funkcje
  • bardzo elastyczny dla prawie wszystkich narożników
  • open source

Con:

  • nie tak łatwo zacząć
  • nie z MS
  • jest wiele narzędzi, ale trzeba szukać

Pomiędzy 2 ORMs

Wybrałbym LinqToSql Jeśli:

  • db-schema = = klasy
  • używaj tylko MS SQL Server
  • Sklep zezwala tylko na MS-produkty

Wybrałbym Nhibernate Jeśli:

  • richer objectmodel
  • dziedzictwo db-schema
  • DB inne niż MS SQL Server lub obsługują wiele
  • performance critical (myślę, że NH ma więcej funkcji do optymalizacji wydajności niż LinqToSql)

Uwaga: to jest mój osobisty pogląd. Zajmuję się głównie (szalonymi) starszymi zadaniami dbs i złożonymi zadaniami ETL, w których model obiektowy bardzo pomaga w porównaniu z SQL.

 2
Author: Firo,
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
2011-05-25 09:43:17

Nie używam (ani nawet nie znam) NHibernate, chcę tylko dać świadectwo: używam LINQ do SQL od około 2 lat z bazami danych MySQL i PostgreSQL (używając DbLinq w systemie Windows, używając Mono w Linuksie i Mac OS X).

Więc LINQ do SQL nie ogranicza się do produktów Microsoft.

Mogę potwierdzić, że LINQ to SQL bardzo dobrze nadaje się do małych i średnich projektów, lub dużych projektów, w których masz absolutną kontrolę nad strukturą bazy danych. Jak wskazują opinie, LINQ do SQL ma pewne ograniczenia, które sprawiają, że jest to nieodpowiednie narzędzie, gdy nie ma bezpośredniego mapowania między tabelami bazy danych a klasami encji.

Uwaga: LINQ do SQL nie obsługuje relacji wiele do wielu (ale można to łatwo osiągnąć za pomocą kilku linii kodu).

 0
Author: CedX,
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
2011-12-06 22:24:58

Główną wadą NHibernate jest niemożność użycia wywołań metody . Nie można ich przetłumaczyć na SQL. Aby to obejść, musisz odtworzyć drzewa ekspresji, co jest trudne do zrobienia.

 0
Author: Oualid KTATA,
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
2012-10-21 01:35:10