Przygody z oprogramowaniem
  • Start
  • Szkolenia
    • Szkolenia otwarte
    • Katalog szkoleń
  • Usługi
    • Konsulting
    • Mentoring
    • Research & Development
  • Blog
  • Wiedza
    • Strefa wiedzy
    • BFsharp
    • SaaS
  • Klienci
  • Kontakt
2

W czym EntityFramework jest lepsze od NHibernate?

6 August, 2012-EntityFramework, Linq, NHibernate

Tak to prawda. Ci co mnie znają, wiedzą o mojej negatywnej opinii o EF, a pozytywnej o NHibernate’ie.
Jednak ostatnio znalazłem bardzo przydatną funkcjonalność, tak naprawdę dowiedziałem się o jej braku w NHibernacie w porównaniu do EF. Otóż wyobraźmy sobie, że mamy zdefiniowaną poniższą metodę, która zwraca na IQueryable – interfejs, który pozwala na komponowanie zapytań linq i dopiero w momencie, gdy chcemy je wykonać, wszystko pakowane jest w jednego SQL i wysyłane do bazy.

public IQueryable<OrderDto> FindOrders()
{
    var dto = from o in EntityManager.CurrentSession.Query<Order>()
              select new OrderDto (o.Id, o.TotalCost, o.SubmitDate, 
                                   o.OrderStatus);

    return dto;
}

Niestety poniższy kod nie działa w NHibernacie – funkcjonalność ta nie została nadal zaimplementowana…
Tylko niektóre operatory są supportowane w tym kontekście, np. Skip i Take.

var r = from dto in finder.FindOrders()
        where dto.OrderStatus == OrderStatus.Draft
        select dto;

var result = r.ToArray();

Oczywiście w EF wszystko ładnie działa, zapytania się komponują i generują poprawne selecty.

  • mkarczewski

    Spotkałem się z podobnym problemem. Niestety, NHibernate dość kiepsko spisuje się po stronie odczytu. Nawet wsparcie mapowania do DTO wydaje się stworzone trochę “na siłę”.
    W przypadku podejścia CQRS byłem bardzo zadowolony z połączenia:
    – NHibernate – strona zapisu
    – LINQ-2-SQL – strona odczytu

    LINQ służyło jedynie do mapowania widoków bazodanowych 1:1 na obiekty, ale sprawdzało się świetnie podczas generowania dość złożonych zapytań uwzględniających uprawnienia, struktury organizacyjne i stronicowanie.

  • Michał Mac

    Dokładnie, w CQRS po stronie read ORM jest zazywczaj zbyt ciężki, wystarczą proste mechanizmy typu: procedury (jeśli mamy super admina, który nie widzi świata bez nich), sql reader i automapper, wygenerowany nowy model EF bądź ewentualnie LINQ2SQL ( ale ta tachnologia nie jest albo nie będzie w niedługiej przyszłości wspierana).

    Natomiast w pragmatycznym podejściu, gdzie mamy model Read oparty o jedną bazę (bez projektorów, bądź tylko z niewielką ich ilością) w 3NF, wtedy fajnie mieć możliwość pobierania i komponowania LINQ na obiektach domenowych. Choć nie można zapomnieć o poprawnej enkapsulacji w encjach, co często powoduje, że niektóre dane nie są dostępne z poziomu LINQ.

Kategorie

Architecture BFsharp Blog Business Framework C# CqRS DDD Debugging DSL EntityFramework Formula JavaScript Linq NHibernate SaaS Silverlight SQL Visual Studio WPF Wzorce

O mnie


RSS Feed

© macmichal.pl 2011 Wszystkie prawa zastrzeżone

Używamy ciasteczek, jeśli kontynuujesz zwiedzanie strony, zakładamy, że wyrażasz zgodę na ich używanie.RozumiemCzytaj więcej