Temat: [Poszukiwany] Fachowiec Entity Framework
Sebastian O.:
Tu to już pytanie o charakter aplikacji. My z reguły robimy pośrednią warstwę - nazwij to serwisem, repozytorium, w zasadzie jeden pies. Tak jak napisałem, nie chciałem zaprzęgać EF do roboty, bo miałem sporo problemów z utrzymaniem kodu (model first) itd., więc w sumie skończyło się na tym, że do "ciężkich" zapytań używam funkcji lub procedur (funkcja o tyle fajne że queryable) zmapowanych na Linq2Sql* - zawsze możesz użyć hinta, joina po konkretnym indexie itd. Natomiast te obiekty, które wymagają edycji z jakiegoś tam formularza, mapujemy sobie AutoMapperem z obiektu modelu na obiekt biznesowy i potem powiązanie z kontekstem lub wstawienie. Poważniejsza jazda zaczyna się, gdy masz obiekty agregujące inne obiekty, przy aplikacjach webowych zmorą jest utrzymywanie stanu takiego obiektu - ile to już razy kląłem jak zapomniałem o tym, że obiekt trzyma listę, a ja wysyłałem tam nulla i mi wywalało wszystko co powiązane.
* O dziwo nadal L2S jest dla mnie wygodniejszy, choć próbowałem już różnych podejść do EF - code first (najsensowniejszy imho), model first i database first.
PS. Dużym plusem na korzyść EF są migracje, które są fajne, ale póki co ciężko mi je było ujarzmić.
Ten post został edytowany przez Autora dnia 17.08.13 o godzinie 16:18