W zasadzie pytanie powinno brzmieć: dlaczego Entity Framework szybko nie stanie się moim ulubionym O/R Mapperem? Po kilkuletniej przygodzie z NHibernate postanowiłem, jakiś czas temu, sprawdzić jak się ma konkurencja. Po szumnych zapowiedziach Microsoftu o inwestowaniu ogromnych sił i środków w rozwój ich flagowego, jak się okazuje, O/R Mappera sięgnąłem po Entity Framework. Coś musi być na rzeczy bo w „branży” dwie litery EF stały się mocno popularne – wręcz trendy. Zachęcony tym całym szumem wokół tej technologii, a także mając w pamięci prelekcję Julii Lerman z C2C’09 stworzyłem swój pierwszy projekt w EF. Hmm … ładny designer encji;). Tu się wszystko skończyło – dawno nie byłem tak rozczarowany! Dwie kwestie rozłożyły wszystko:
- obiekty domeny nie są POCO
- O/R mapper nie jest „Persistence Ignorance”
Obie te dwie cechy mają ze sobą wiele wspólnego. Przede wszystkim mój kod z użyciem EF posiada zbyt wiele zależności do konkretnych technologii łamiąc zasady architektury aplikacji biznesowych jak i wielu wzorców projektowych. Oczywistym mogło by się wydawać to, iż O/R Mapper nie powinien wymagać dziedziczenia encji po własnych klasach. Tak samo oczywiste jest to, że domena aplikacji nie powinna mieć świadomości o mechanizmie zapisu/pobierania danych. A jednak! Bez sarkazmu i zupełnie szczerze mówiąc, nie rozumiem tak wielkiej ignorancji twórców EF. Przyglądam się i nadal kibicuję EF mając nadzieję, że kolejne wersje przyniosą znaczące zmiany w tych dwóch kwestiach. Tymczasem zostaję przy sprawdzonym NHibernate.
Beniamin Zaborski
