Temat: ASP.NET - jakiej metody dostępu do baz danych używacie?
Bartosz Rakowski:
chętnie bym się dowiedział, jakie problemy z EF kolega wcześniej z tym wątku miał na myśli w związku z większymi projektami.
używaliśmy EF, NET 4.0, Linq2Entities i WCF RIA services po stronie serwera, a RIA + SL po stronie klienta. nie jest to trudniejsze niż inne podejścia, których także trzeba się nauczyć. owszem, były jakieś problemy, ale albo je rozwiązaliśmy, albo nie wiem o tym, co przed nami... chętnie bym się dowiedział o co koledze chodziło.
Zakładam że chodziło o mnie? :), nie używałem EF w wersji 4.0 ale mogę co nieco powiedzieć o pierwszym wydaniu dla 3.5.
Nasz schemat miał ok 200 tabel włączenie tego pod jeden Entity Model powodowało załamanie designera, oraz załamanie wydajności, należało grzebać palcem w xmlach (które są znacznie bardziej skomplikowane niż te z NH np). Kolejnym problemem była rozszerzalność każdorazowo gdy ktoś pozmieniał coś w xmlu oraz inna osoba pobierała projekt otworzyła sobie model i bum wszystkie zmiany znikały, model generował się na nowo, można było go oczywiście wyłączyć ale należy o tym pamiętać. To są fakty które nie tak wpływają na wydajność lecz powodują frustrację.
Kolejnym problemem były procedury składowane które zwracają zestaw danych, należało udzielać się do brudnych sztuczek w xmlu, jako że EF ich nie wspierał, dostępne były tylko funkcje out of the box.
Podzapytania to katastrofa, były tak okrutnie wolne że select na małym zbiorze danych zajmował ponad 10 sek gdy robiło się to metodą LINQ ostatecznie prawie każde zapytanie było pisane w ENTITY SQL, więc jako String i strong typing wyleciał przez okno, selecty generowane przez EF były ogromne (4K linijek czasami) podobno teraz to poprawili ale wtedy były mało wydajne.
Czasami zdarzało się że Model się de synchronizował, co powodowało naprawdę dziwne zachowania, oraz jeszcze dziwniejsze wyjątki przy jego walidacji, generator potrafił coś źle zrobić.
W efekcie nasz wielki schemat podzieliliśmy na ok 20 mniejszych Domen gdzie każda miała do 10 zmapowanych obiektów (warto tu nadmienić że nasze obiekty były dość ciężkie) gdyż każda większa ilość powodowała znaczące obniżenie wydajności, było to niezłe rozwiązanie ale ograniczenia były znaczne bo natychmiast traciliśmy spójność grafu jako całości, nie można było joina zrobić pomiędzy obiektami z różnych domen a czasami było to wymagane (jest na to sposób).
Fajną rzeczą było dziedziczenie w modelach pomiędzy obiektami, lecz ono spowolniało całą zabawę jeszcze bardziej, obiekty complex teoretycznie były zaimplementowane lecz nie out of the box więc należało je pisać w xmlu ale po kilu nie udanych próbach okazało się że nie do końca działają gdyż nie było zgodności ze scheemą EF oraz skutkowało to wyjątkiem.
To po krótce moje wrażenia co do EF dla 3.5 w projekcie, mam nadzieje ze nowy EF naprawił co nieco z tych rzeczy które mnie w nim denerwowały, dla porównania z NH + Fluent nigdy nie miałem podobnych problemów, jedynie początkowa konfiguracja pierwszy raz sprawiała mi pewne problemy.
пропозиції роботи
