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

30

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?

Nickz
źródło
8
Nie ma najlepszego. Istnieje wiele opcji, które mają zestaw zalet i wad. Każdy przynosi coś innego do stołu.
Tony
Jedno twierdzenie na temat terminologii: powiedziałbym, że SubSonic z pewnością nie jest ORM. Więcej… ekspozera relacji do obiektu. Może generować tylko klasy bezpośrednio odzwierciedlające schemat tabeli bazy danych. W większości działa dobrze, ale ten punkt konstrukcyjny jest dość ważny, ponieważ znajduje się na zupełnie innym polu gry niż EF i NHib.
quentin-starin
1
@qstarin: dzięki temu SubSonic jest tak samo ORM jak LINQ-to-SQL.
John Saunders
bardzo dobra uwaga, John i qstarin. to cienka linia, którą można by zaklasyfikować jako ekspozytora relacji relacyjnych do obiektów. SubSonic 3.0 oferuje funkcje zgodne z koncepcjami ORM. Wiki mówi. „konwersja danych między niekompatybilnymi systemami typów w obiektowych językach programowania. W efekcie powstaje„ wirtualna baza danych obiektów ”, z której można korzystać w języku programowania.” ponadto na ormbattle.net SubSonic jest uważany za ORM. Dziękuję wam obojgu za opinie
Nickz
2
Widzę Linq-to-SQL bardziej jak gloryfikowany generator sql niż ORM ...
fretje

Odpowiedzi:

43

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.

Renaud Bompuis
źródło
3
Wiedząc o tym, co wybrałeś?
Steven Evers,
dzięki Renaud Bompuis, nie słyszałem o niektórych z wymienionych ORM. Dostarczone informacje to świetne jedzenie do przemyślenia, dzięki.
Nickz
1
@SnOrfus: nadal korzystam z XPO, ale przechodzę do migracji do LLBLGen, jest solidny, dojrzały i pozostajesz pod kontrolą (więc możesz nadal brudzić sobie ręce, jeśli potrzebujesz / chcesz) i pozwala to na bardziej odpowiednie rozdzielenie problemów i ponowne użycie obiektu (przez adapter).
Renaud Bompuis
3
Warto zauważyć, że Entity Framework jest teraz w wersji 4.1 i na pewno warto go teraz obejrzeć.
Sean Kearon
Uwielbiam przechowywane procesy na serwerze i LINQ na kliencie. Spróbuj obniżyć głosowanie! Bez krzywej uczenia się, bez niespodzianek, bez wersjonowania, bez niespodzianek!
NoChance,
14

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.

Sam J
źródło
Bądź ostrożny, NHibernate może być trudny w przypadku bardziej skomplikowanych modeli. Wszystko jest dobrze udokumentowane i ma bardzo dobry sens, ale jeśli nie jesteś świadomy, możesz napotkać problemy. To znaczy, krzywa uczenia się jest wysoka, ale jest doskonała.
Matt Olenik,
dzięki Sam, nie korzystałem z nhibernate, jednak wydaje się, że wymaga ono obszernej konfiguracji w porównaniu do SubSonic, Linq-to-SQL i Entity Framework. To nie byłoby idealne dla mojego zespołu programistów.
Nickz
Jeśli jesteś w ogóle zainteresowany, Ayende organizuje warsztaty NHibernate na konferencji YOW Australia - yowconference.com.au/melbourne/events_tracks/… - w listopadzie / grudniu. Jeden z facetów, z którymi pracuję, przez jakiś czas go używał, więc mogłem się go nauczyć.
Sam J
3
@Nick Większość konfiguracji można zautomatyzować. Sprawdziłbym również płynny dodatek.
stonemetal
@Nick, @stonemetal zgodził się, Fluent NHibernate znacznie ułatwia sprawy. Nie jest tak szybki jak SubSonic, ale nadal warto go zobaczyć.
Matt Olenik,
6

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.

Jesse C. Slicer
źródło
Słyszę, jescze, w poprzednich pracach byłem na podobnej pozycji ORM-ów rodzimych. dzięki za opinie.
Nickz
3
Domowe ORM zawsze są do kitu. Najlepsze są zawsze gorsze niż najgłupsze publiczne ORMy.
Jaco Pretorius
@JacoPretorius Są na to kontrprzykłady ... ale „z reguły”…
pst
3

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).

Jeremy Roberts
źródło
3

[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.

Dennis Garavsky
źródło
Nadal używam XPO i cieszę się z nadchodzących aktualizacji.
Renaud Bompuis,
2

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.

fjxx
źródło
1

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.

Murph
źródło
Dziękuję za opinię Murph. Zgadzam się na „najlepszą” ORM. Jednak zamierzam wprowadzić taką większą standaryzację. Użycie jednego z ORM pomoże nowym programistom i obecnym programistom w moim zespole. Obecnie, gdy korzystanie ze wszystkiego, poddźwiękowego, ADO.net, linq-to-sql itp., Przemieszczanie się między projektami i konserwacją staje się coraz trudniejsze.
Nickz,
Och, nie mam problemu z wyszukiwaniem najbardziej odpowiedniej ORM dla twoich przypadków użycia i całkowicie zgadzam się z celowością zadania pytania poniżej. Właśnie prowadzę daremną kampanię przeciwko użyciu słowa „BEST” w pytaniach dotyczących
wymiany stosów
1

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

Jogin Yang 007
źródło
XAF jest oparty na XPO, który jest ORM. Sam XAF opiera się na tym i dodaje logikę i „automatyczny” interfejs użytkownika itp.
Sascha,
Wyjaśnij, dlaczego Twoim zdaniem DevExpress XAF ułatwi życie programistom.
@Sascha, dzięki za podpowiedź. Poprawiłem swój post.
Yogi Yang 007,
@Mark, XAF wraz z XPO działa zarówno jako generator ORM, jak i generator interfejsu użytkownika, dzięki czemu programiści mogą tworzyć w pełni funkcjonalne aplikacje w .NET przy minimalnym kodowaniu.
Yogi Yang 007,
Jeden komentarz z mojej strony do XAF: Jest to świetny system dla średnio skomplikowanych środowisk logiki biznesowej, ponieważ przyspiesza czas programowania dla czynników. Minusem jest to, że na danych granicach jego przedłużenie jest bardzo czasochłonne. Na przykład hierarchiczni użytkownicy (wraz z logiką podobną do zespołów) i „użytkownik może widzieć tylko elementy siebie i / lub swoich podwładnych” nie są obsługiwane od razu po wyjęciu z pudełka. Tak więc XAF ma zalety i wady, więc naprawdę należy to ocenić, czy jest odpowiednie dla projektu - IMHO. Ale to zdecydowanie dobrze zrobiony fundament, jeśli pasuje.
Sascha,
1

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.

TMN
źródło
2
Tak, jestem fanem EF 4, który jest znacznie lepszy od poprzedniej wersji.
Nickz
1

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.

rmac
źródło
LightSpeed ​​firmy MindScape wygląda naprawdę interesująco.
Nickz
1

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.

Wayne Molina
źródło
0

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.

William
źródło
4
Byłoby pomocne, gdybyś wyjaśnił dlaczego.