No to przygoda z Entity Framework zakończyła się dość szybko :) zresztą nie dziwie się po tym jak zostały wykonane testy wydajnościowe systemu, który bezpośrednio na bazie danych działał 800% szybciej po wszystkich możliwych sztuczkach wydajnościowych Entity Frameowrk na których wprowadzenie czas mieliśmy.

Wraz ze zmianą sposobu dostępu do danych należało wygenerować CRUD dla tabel już znajdujących się. Nie było ich dużo, bo około 20, jednak operacji CRUD per tabela, które miały powstać było dziewięć:

  • Insert
  • InsertOrUpdate
  • Update
  • SelectAll
  • SelectByPk
  • SelectByFk
  • Delete
  • DeleteByPk
  • DeleteByFk

Łatwo więc policzyć iż 20*9 = 180 – jest to liczba w przybliżeniu w zależności od liczby PK i FK, oczywiście nie wszystkie SP są i będą wykorzystane, ale takie było zapotrzebowanie i jak teraz ktoś potrzebuje takich SP to od razu je ma. Jaki widzę problem? To niech pierwszy chętny się zgłosi do napisania tych procedur! Najlepsze jest to, że podczas definiowania co jest potrzebne mówi się przeważnie, że wszystkie, a dopiero jak ktoś spędzi czas nad tym dowiaduje się, że połowa była zbędna i mógłby jej nie pisać… ech.

Jeżeli miałbym to pisać ręcznie to zajęłoby mi to około jednego do dwóch dni roboczych i to roboty głupiego a gdyby potem doszły kolejne tabele to miałbym kolejną pracę. Dlatego też stwierdziłem, że znów uśmiechnę się do swojego ulubionego niegdyś narzędzia, którego już od dwóch lat na oczy nie widziałem – CodeSmith Tools. Swoją przygodę z CST zakończyłem przy projekcie IT Core, kiedy to na podstawie meta danych list generowaliśmy sobie obiekty dostępu do elementów listy i działania na liście. Taki ogólny wrapper, zamiast pisać SPList.ListItems[0][„name”] pisaliśmy List.Name – bardzo dobre rozwiązanie, jednakże przy większych projektach może okazać się trochę spowolniające pracę (lista musiała istnieć zanim można było napisać linijkę kodu, zmiana listy wymagała nowej generacji kodu itp. itd.) i wydajność rozwiązania, może kiedyś dopracuje te szablony i je udostępnię, zobaczymy.

Wracając do generowania SP. Wpadłem na pomysł, że można by wykorzystać CST do tego by nam wygenerował wszystkie procedury, kosztowałoby mnie to pół dnia pracy a zyskałbym wolność i swobodę przy kolejnych zmianach. Więc odkopałem swoją licencję CST, odpaliłem i zanim zacząłem pisać szablon przejrzałem już dostępne.

Ku mojemu miłemu zaskoczeniu :) Szablon do generowania procedur był już domyślnie dostępny :) i to nie w jakiś zaawansowanych funkcjach, ale jako „przykładowy szablon” :)

Jaki morał z tej historii?

Syndrom NIH, powoduje, że na nasze oczy nakładane są klapki i jesteśmy raczej chętni poświęcić dwa dni pracy na stworzenie czegoś ręcznie lub napisanie funkcjonalności, która już istnieje. Warto wiedzieć co jest dostępne na rynku, nie trzeba tego bardzo dobrze znać, ale ważne jest to by wiedzieć do czego można daną rzecz wykorzystać.

PODOBNE ARTYKUŁYWIĘCEJ OD AUTORA

6 KOMENTARZE

  1. Witam,
    Coś z pierwszego dłuugiego zdania nie zrozumiałem, czy skończyła się przygoda z Entity Framework bo skończyliście projekt czy bo EF jest do niczego :)

    Mógł byś uściślić, czy używacie, bo dało się z niego fajnie wycisnąć dużo, czy po prostu nie działa? :)

  2. @Piotr

    Wydajnosc EF byla tak niska, ze zrezygnowalismy. Dodatkowo pojawialy sie porblemy podczas aktualizacji modelu – np.: usunales kolumne w bazie danych i aktualizujesz model to on jej nie usunie. tylko przy buildzie Ci powie ze jest nie z mapowana kolumna.

    Czasmi ni z tad ni z owad bral tabele sys… a czasami ich nie widzial.

    Z SP byl podobno problem, ale za pomoca EF Extensions dalo sie zyc.

    Tak naprawde pisanie EF by bylo to wydajnie rowna sie z pisaniem za pomoca trips&tricks: by przypisac klucz do pola FK w entity nalezy… zamiast pobrac obiekt i go przypisac itp tid.

    Jednak tak jak na poczatku napisalem. EF jest niewydajny i zrezygnowalismy z niego dla starego dobrego SqlConnection z SqlCommand i SP.

    System dziala 800% wydajniej niz z wykorzystaniem EF.

    Gutek

  4. Jakub,

    Czy możesz wysłać mi informację o konkretnych rzeczach, z którymi były problemy w EFv1? Byloby super gdybyś mógł przesłać model, z którym były problemy wydajnosciowe i kawalki kodu ktore dzialaly szczegolnie wolno.

    Moj email: jaroslaw dot kowalski -at- microsoft dot com

    FYI: W nowej wersji EF będzie wsparcie dla prawdziwych kluczy obcych, bez konieczności stosowania sztuczek o ktorych mowisz, do tego POCO, lepsza obsługa N-Tier, itp.. Sporo inwestujemy też w wydajność itp. Więcej szczegółów znajdziesz na http://blogs.msdn.com/efdesign/

  5. @rzyletka

    Ze wzgledu na klienta z NH nie moglismy korzystac, a ze wzgledu na dead line, po EF nie mielismy czasu na testy i wybory innej technologii

    @Jarek

    Wyslie Ci to co bede mogl i to co jeszcze gdzies sie ostalo – nie wiem czy jakis backup starego rozwiazania byl robiony po zmianach.

    Co do v2, dzieki, wiem i zesmy sie smieli mowiac “przydaloby sie to” a nastepnie na blogu “bedzie to w wersji 2” :)

    Ogolnie mowiac EF jest fajny i jest to dobry pomysl, jednak w naszym wypadku kiedy zalezalo nam na wydajnosci, w wersji 1 nie sprawdzal sie on tak, jakbysmy chcieli/jak zakladalismy.

Comments are closed.