Jakie są kryteria oceny ORM for.NET? [Zamknięte]

Patrzę na ocenę ORM.

Korzystałem z SubSonic , Linq-to-SQL i Entity Framework . Mam zespół programistów, od juniorów po seniorów.

Jakie są kryteria oceny ORM for.NET?

To pełne pytanie.
Istnieje wiele bardzo dobrych ORM podchodzących do tematu z różnymi filozofiami.
Żadne z nich nie jest doskonałe i wszystkie stają się złożone, gdy tylko zboczysz ze złotej ścieżki (a czasem nawet, gdy będziesz się jej trzymać).

O co powinieneś zadać sobie pytanie przy wyborze ORM:

1. Co trzeba dla ciebie zrobić?
   Jeśli masz już zestaw wymagań dotyczących aplikacji, powinieneś wybrać ORM, który lepiej je spełnia, zamiast hipotetycznego „najlepszego”.

2. Czy Twoje dane są udostępniane, czy tylko lokalne?
   Wiele włochatości w ORM jest spowodowanych tym, jak obsługują współbieżność i zmiany danych w bazie danych, gdy wielu użytkowników trzyma wersje tych samych danych.
   Jeśli Twój magazyn danych jest przeznaczony dla jednego użytkownika, większość ORM wykona dobrą robotę. Zadaj sobie jednak trudne pytania w scenariuszu z wieloma użytkownikami: w jaki sposób obsługiwane jest blokowanie? Co się stanie, gdy usunę obiekt? Jak wpływa na inne powiązane obiekty? Czy ORM działa blisko metalu zaplecza, czy też buforuje dużo danych (poprawiając wydajność kosztem zwiększonego ryzyka stagnacji).

3. Czy ORM jest dobrze przystosowany do twojego rodzaju aplikacji? Z konkretnym ORM może być trudno pracować (duży narzut wydajności, trudny do kodowania), jeśli jest używany w usłudze lub siedzi w aplikacji internetowej. Przeciwnie, może być świetny dla aplikacji komputerowych.

4. Czy musisz zrezygnować z ulepszeń specyficznych dla bazy danych?
   ORM zwykle używają zestawu SQL o najniższym wspólnym mianowniku, aby upewnić się, że działają z wieloma różnymi zapleczami bazy danych.
   Wszystkie ORM będą narażać na szwank dostępne funkcje (chyba że są ukierunkowane konkretnie na jeden backend), ale niektóre pozwolą na wdrożenie dodatkowych zachowań w celu wykorzystania określonych ulepszeń dostępnych w wybranym backendie.
   Typowym rozszerzeniem specyficznym dla bazy danych jest na przykład możliwość wyszukiwania pełnotekstowego; upewnij się, że ORM zapewnia ci dostęp do tych funkcji, jeśli ich potrzebujesz.

5. Jak ORM zarządza zmianami w modelu danych?
   Niektórzy mogą aktualizować DB automatycznie w ramach określonego środka, inni nic nie robią i będziesz musiał sam wykonać brudną robotę; inne zapewniają strukturę do obsługi zmian, która pozwala kontrolować aktualizacje bazy danych.

6. Czy chcesz powiązać swoją aplikację z obiektami ORM, czy wolisz obsługiwać POCO i używać adaptera w celu zachowania trwałości?
   Ten pierwszy jest zwykle prosty w obsłudze, ale wszędzie tworzy zależności od obiektów danych specyficznych dla ORM, drugi jest bardziej elastyczny, kosztem nieco więcej kodu.

7. Czy kiedykolwiek będziesz musiał zdalnie przesłać swoje obiekty?
   Nie wszystkie ORM są równe, jeśli chodzi o pobieranie obiektów ze zdalnego serwera, przyjrzyj się dokładnie temu, co jest możliwe lub niemożliwe. Niektóre są skuteczne, inne nie.

8. Czy jest ktoś, do kogo możesz się zwrócić o pomoc?
   Czy jest dobre wsparcie handlowe? Jak duża i aktywna jest społeczność wokół projektu?
   Jakie problemy mają obecni użytkownicy z produktem?
   Czy dostają szybkie rozwiązania?

Kilka ORM, na które spojrzałem:

• XPO
  Od dewelopera Express: jest mały i prosty, zorientowany na kod. Używają go do tworzenia aplikacji eXpressApp .
• NHibernate
  jest darmowy, ale krzywa uczenia się jest dość stroma. Wiele gadżetów, ale czasami trudno znaleźć to, co jest naprawdę istotne w całej podzielonej dokumentacji.
• LLBLGen Pro to
  bardzo dojrzały projekt, nie najprostszy, ale poświęcono mu wiele uwagi.
• Entity Framework
  GEtting tam. Ostatnie wydania są całkiem niezłe, a MS słucha, choć wciąż jest trochę młody w porównaniu do innych, bardziej dojrzałych ORM.
• DataObject.Net
  Wygląda obiecująco, ale jest też trochę nowy, ryzykując ważny projekt IMHO. Jednak dość aktywny.

Oczywiście jest wiele innych.

Możesz rzucić okiem na kontrowersyjną stronę ORM Battle, która zawiera niektóre testy wydajności, chociaż musisz pamiętać, że surowa prędkość niekoniecznie jest najważniejszym czynnikiem dla twojego projektu, a producentami strony jest DataObject.Net.

Używam NHibernate i uważam, że jest całkiem niezły.

W moim przypadku połączony z bazą danych MS Sql, ale możesz połączyć się z innymi bazami danych.

Uruchomienie nie trwa długo - wystarczy zmapować obiekt do modelu - używam pliku xml, ale możesz to zrobić płynnie w kodzie. Jest świetna społeczność i osobiście uważam, że praca Ayende jest bardzo pomocna - używam NHProf, który jest narzędziem do profilowania SQL.

Najczęściej używam funkcji „po wyjęciu z pudełka” - mapowania obiektów prostych, ale używam również języka zapytań Hibernacji, który jest dość łatwy do opanowania.

Niestety, w moich ostatnich trzech pracach mieliśmy trzy domowe ORM. W każdym przypadku ssały głównie z różnych powodów.

Niedawno oceniam Entity Framework 4 i jego obsługę POCO ( tutaj jest miła instrukcja ) i jestem pod wielkim wrażeniem tego, jak ładnie trzyma się z mojej twarzy i sprawia, że ​​mam wrażenie, że znów programuję, a nie gromadzę dane.

Porównanie ORM i testy porównawcze na ORMBattle.NET

Bardzo lubię Linq do Sql. To proste i ma przyzwoitego projektanta. Mam jednak nadzieję, że zakończę to na korzyść ram Entity. Chciałbym mieć możliwość modyfikowania generatorów, aby mieć dostosowane obiekty.

Największą zaletą, jaką mają one w porównaniu z innymi (moim zdaniem), jest to, że są nieszablonowe z VS. Jest to również negatywne, ponieważ jesteś na łasce stwardnienia rozsianego (patrz Linq do Sql).

[ZASTRZEŻENIE: Pracuję dla DevExpress]

Można zobaczyć screeny z typowych aplikacji stworzonych przez ram aplikacji DevExpress tutaj . Ta strona zawiera również bardzo krótką recenzję naszych produktów. Aby uzyskać bardziej szczegółowe informacje na temat przyczyny , sugeruję przejrzenie odpowiednich stron produktów na naszej stronie internetowej.

Jeśli chodzi o DevExpress XAF i XPO, oto dobre wyjaśnienie, dlaczego wybrać nasze ramy aplikacji. Ponadto zapewniamy wsparcie i dokumentację, która jest również ważna i warta wspomnienia. W razie jakichkolwiek pytań prosimy o kontakt.

Używamy NHibernate + Fluent NHibernate, z Linq-to-Sql w małych projektach. Powodem tego jest:

1) (Nie jest to główny powód) Wydaje się, że NHibernate ma wyższy współczynnik „szacunku” wśród programistów (czy to prawda?),

2) W porównaniu z linq-to-SQL, nHibernate pozwala na mapowanie ORM między obiektami Db i obiektami, które nie mapują 1-na-1,

3) Nie porównaliśmy dokładnie nHibernate z Entity Framework 4.0, ale oto dobre porównanie: http://ayende.com/blog/archive/2010/01/05/nhibernate-vs.-entity-framework-4.0.aspx

nHibernate ma dość stromą krzywą uczenia się, a jego mapy XML mogą być dość szczegółowe, ale zacznij od dokumentacji witryny Fluent Nhibernate i przejdź wstecz.

Nie ma „najlepszego” frameworku ORM, ponieważ wszystkie mają różne kombinacje mocnych i słabych stron i często zdarza się, że jeśli programiści postanowią skupić się na ulepszaniu jednego obszaru, to inne obszary będą cierpieć w porównaniu (kod pierwszy vs najpierw model, a najpierw baza danych).

Z drugiej strony istnieje wiele bardzo dobrych, z których niektóre lepiej pasują do twoich osobistych okoliczności i filozofii niż inne.

Edycja: Ze względu na swoją wartość, obecnie używam Linq do SQL - głównie dlatego, że tam jest, choć częściowo dlatego, że robi to dobrze przy minimalnym wysiłku i prawdopodobnie przejdzie do Entity Framework ponownie „ponieważ jest tam” (chociaż podobnie jest też dużo o EF4, które są odpowiednie, a także niektóre rzeczy, które są złe). Problemem, szczególnie w przypadku tych ostatnich, musiałaby być wydajność, ale w większości przypadków nie jest to ogromny problem, a możliwość uruchamiania danych dynamicznych i danych OData z modeli (L2S i EF) przynosi mi znaczne korzyści pod względem „ tanie ”wygrane.

Radzę rzucić okiem na DevExpress XPO . To wraz z DevExpress XAF ułatwi życie programistom po przekroczeniu krzywej uczenia się.

Mieliśmy szczęście z Entity Framework. Nasza sytuacja jest jednak nieco niezwykła - zbieramy dane dla zespołu raportującego, więc oni faktycznie projektują bazę danych. Otrzymujemy DB, a następnie po prostu używamy EF do generowania z niej klas dostępu do danych. Działa świetnie dla nas, ale po prostu ładujemy masowo dane, więc nie mogę ręczyć za to, jak dobrze sobie radzi w środowisku bardziej transakcyjnym.

NHibernate (+ FluentNHibernate) byłby dla mnie opcją domyślną. Jest bardzo elastyczny, rozszerzalny i wytrzymały. Ma ogromną liczbę użytkowników i jest bardzo aktywnie utrzymywana. Minusem jest stroma krzywa uczenia się.

LightSpeed ​​firmy MindScape jest prosty i przyjazny dla użytkownika, ale wciąż dość elastyczny i zdolny. Ma powierzchnię projektanta, taką jak L2S / EF i implementację UnitOfWork.

Cóż, nie ma „najlepszego” wyboru, ale powiedziałbym, że zwykły stary Linq na SQL spełnia twoje potrzeby. Nie jest to „prawdziwa” ORM sama w sobie, ale jest bardzo lekka i daje elastyczność pisania kodu, nie będąc tego świadomym, jeśli ma to sens. Chodzi mi o to, że możesz kontynuować pisanie kodu w normalny sposób, bez konieczności faktycznej znajomości Linq poza posiadaniem dbmlpliku (ów). Nadal można na nim pisać abstrakcje, używając wzorców Repozytorium lub Bramy, a L2S spełnia główną rolę ORM, którym jest ominięcie niedopasowania obiektowo-relacyjnego.

Entity Framework jest trochę ciężki i chociaż trochę nim się trochę bawiłem, jest bardziej „na twoją twarz” niż podstawowy Linq do Sql, ale EF jest o wiele bardziej prawdziwym ORM niż Linq. Spojrzałbym na wszystkie kryteria, których szukasz w ORM. Czy tylko dlatego, że chcesz uniknąć konieczności pisania surowego kodu SQL lub, co gorsza, mieć setki procedur przechowywanych? Czy potrzebujesz dodatkowych funkcji, których nie może zapewnić surowy Linq do Sql? Musisz odpowiedzieć na te pytania, ale w oparciu o twoje krótkie wymagania („lekki i łatwy w użyciu”) Myślę, że Linq jest nieco łatwiejszy niż coś takiego jak Subsonic i jest wbudowany w Visual Studio.

ECO :) To znacznie więcej niż ORM, włączając w to automaty stanów i obsługiwane pliki OCL (a mianowicie EAL). Istnieje darmowa wersja z ograniczeniem do 12 klas domen, które moim zdaniem powinny być całkiem fajne w przypadku małych projektów.