Mógłbyś rozszerzyć "do bani" dlaczego? Przecież jest częścią platformy to chyba musi być "dobry" skoro go tam umieścili i wszyscy co pracują z ASP.NET MVC chyba go wykorzystują?
Nie jest dobry, po prostu M$ promuje swoje produkty razem. No i to chyba jest przyczyna, dla której większość projektów w .NET korzysta z EF.
Czemu EF jest do bani?
- Generuje okropny kod SQL.
- Wbrew prawom matematyki i ludzkiego rozumu, domyślnie ucina liczby dziesiętne zamiast zaokrąglać: (https://msdn.microsoft.com/en-us/library/system.data.entity.sqlserver.sqlproviderservices.truncatedecimalstoscale%28v=vs.113%29.aspx)
- Jego twórcom trzy lata zajęła implementacja dialektu SQL 2012 (chodzi mi o
offset
i fetch
). Powtarzam - trzy lata dostosowanie jednego produktu M$ do innego produktu tej samej firmy.
- Nie potrafi samo generować ID.
- Obsługuje tylko jeden typ kolekcji, nie można np. zmapować słownika, listy ani baga, tylko ten
DbSet
.
- Nie posiada wbudowanego second level cache.
- Wspiera niewiele baz danych (w praktyce jedną).
- Ma niewielkie możliwości rozszerzania, np. brak oddzielnych zdarzeń przed/po insert/update/delete/load.
- Brak operacji wsadowych - skasowanie np. wszystkich rekordów spełniających dany warunek wymaga najpierw ich załadowania z bazy albo napisania SQL.
- Brak możliwości leniwego ładowania pojedynczych właściwości.
- Brak możliwości utworzenia obiektu Proxy bez ładowania go z bazy.
- Optimistic concurency tylko na
rowversion
albo na wszystkich kolumnach na raz.
- Brak wyliczanych właściwości.
- Brak filtrów globalnych.
- Brak query-by-example.
- Brak prostej możliwości budowania zapytań po nazwach właściwości. (Z GUI zazwyczaj nazwę właściwości, po której sortujesz albo filtrujesz dostajesz jako
string
, a EF jest tak nowoczesny tępy, że łyka tylko LINQ.)
- Ma bezsensowną architekturę -
*Context
trzyma konfigurację, model, metadane oraz jest UoW i trzyma listę śledzonych encji. Gdzie SRP ja się pytam?
Czy może jakieś alternatywy? Coś z rodziny N?
Ja preferuję NHibernate, ale nie wiem, czy to alternatywa, bo to tak jakby nazwać prom kosmiczny alternatywą trampek...
Moment moment, MVC Model ma zawierać logikę? Przerobiłem wiele "tutoriali" i kilka książek i w każdej model był jedynie czymś takim:
Takie klasy mogą też być w modelu. Ale model, to wszystko, co nie jest ani widokiem ani kontrolerem. Logika biznesowa, operacje na danych - to wszystko powinno mieć miejsce w modelu. Model to wiele warstw, a nie jeden katalog z klasami w MVC.
Tutoriale i książki po pierwsze upraszczają wszystko, po drugie ich autorzy często nie wiedzą co to jest MVC.
Tak jak możesz pisać nieobiektowo w języku obiektowym, tak samo możesz nie stosować się do wzorca MVC korzystając z frameworka MVC.
Proponuję zajrzeć do źródeł: http://st-www.cs.illinois.edu/users/smarch/st-docs/mvc.html
In the MVC paradigm the user input, the modeling of the external world, and the visual feedback to the user are explicitly separated and handled by three types of object, each specialized for its task. The view manages the graphical and/or textual output to the portion of the bitmapped display that is allocated to its application. The controller interprets the mouse and keyboard inputs from the user, commanding the model and/or the view to change as appropriate. Finally, the model manages the behavior and data of the application domain, responds to requests for information about its state (usually from the view), and responds to instructions to change state (usually from the controller).
(pogrubienie moje)