Temat: [Poszukiwany] Fachowiec Entity Framework

Jak w temacie.

W tym roku szykuje mi się większy projekt i być może będę potrzebował konsultacji z EF.
Szukam kogoś kto pracuje z bazami >= kilkaset tabel.
Będą to głównie problemy projektowe/optymalizacyjne także na pewno nie podstawy.

Osoby zainteresowane proszę o info w tym temacie lub na priv z podaniem stawki za godzinę konsultacji.
Tomasz M.

Tomasz M. never go full
retard!

Temat: [Poszukiwany] Fachowiec Entity Framework

Powiem tylko jedno kilkaset tabel i entity framework raczej ze sobą nie zagra. Znam już takich, którzy portowali aplikacje z Entity Framework na stare, dobre (jak kto lubi) mechanizmy ADO. Nie zniechęcam, ale zalecam wcześniej mocno rozważyć. U nas najlepszym rozwiązaniem okazuje się być tworzenie contextu L2S i mapowanie tam procedur i udfów, samych obiektów używamy rzadko - to dla średnich projektów. Ale w sumie to samo można osiągnąć bez L2S.

Temat: [Poszukiwany] Fachowiec Entity Framework

Hmm też bym chętnie korzystał z ADO.NET ale .... masz jakiś dobry sposób na bindowanie danych z modelem ?

Bo niezbyt mi się uśmiecha robić tak jak tu:
http://stackoverflow.com/questions/6694098/using-asp-n...

To jest prosty model a przy bardziej skomplikowanych to wychodzi tyle kodu, że masakra ...
Łukasz Wójcik

Łukasz Wójcik Enjoy the code :D

Temat: [Poszukiwany] Fachowiec Entity Framework

EF do prostych zapytań jest ok. Pozostałe raczej bym zostawił procedurom :)
Tomasz M.

Tomasz M. never go full
retard!

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
Tomasz M.

Tomasz M. never go full
retard!

Temat: [Poszukiwany] Fachowiec Entity Framework

Sebastian O.:
Bo niezbyt mi się uśmiecha robić tak jak tu:
http://stackoverflow.com/questions/6694098/using-asp-n...

Nie no, to nędza :) No i średnio bezpieczne, to już lepiej użyć w środku procedury.Ten post został edytowany przez Autora dnia 17.08.13 o godzinie 16:17

Temat: [Poszukiwany] Fachowiec Entity Framework

W Web Formsach to wiadomo tylko ADO.NET z procedurami i fajnie to szło.
Po przejściu na MVC używam EF Code First ale to do mniejszych rzeczy i już bez procedur.

Hmm jeszcze trochę czasu mam żeby na coś się zdecydować :)
Marcin Pasternak

Marcin Pasternak Programista .NET, C#

Temat: [Poszukiwany] Fachowiec Entity Framework

Hm ja spotkałem się z użyciem NH w większych projektach i nawet daje radę.

konto usunięte

Temat: [Poszukiwany] Fachowiec Entity Framework

Sebastian O.:
Jak w temacie.

W tym roku szykuje mi się większy projekt i być może będę potrzebował konsultacji z EF.
Szukam kogoś kto pracuje z bazami >= kilkaset tabel.
Będą to głównie problemy projektowe/optymalizacyjne także na pewno nie podstawy.

Jeśli chodzi o wydajność (programisty i systemu) to odradzam EF i polecam Lightspeed (http://www.mindscapehq.com/products/lightspeed).

Jest to rozwiązanie płatne (i nie tanie), ale się zwraca (tak było przynajmniej w przypadku mojego projektu)
Tomasz M.

Tomasz M. never go full
retard!

Temat: [Poszukiwany] Fachowiec Entity Framework

Marcin P.:
Hm ja spotkałem się z użyciem NH w większych projektach i nawet daje radę.

Też bym szybciej poszedł w NHibernate w dużym projekcie.
Tomasz Anciński

Tomasz Anciński Programista Systemów
Sterowania,
Blumenbecker
Engineering...

Temat: [Poszukiwany] Fachowiec Entity Framework

procedury na serwerze to dobry sposób, ogranicza transfer danych co nie jest bez znaczenia w dużych projektach wykonujących dużo zapytań, do tego można to sobie tak pokombinować, żeby w kodzie decydować z której tabeli aktualnie połykać dane...
ps. a dlaczego kilkaset tabel ??
Marek Kubiś

Marek Kubiś programista c#

Temat: [Poszukiwany] Fachowiec Entity Framework

Sebastian O.:
Hmm też bym chętnie korzystał z ADO.NET ale .... masz jakiś dobry sposób na bindowanie danych z modelem ?
Hmmm .. ale alternatywą dla EF z Fluent API jest .. nie używanie EF czyli intensywne eksplorowanie bazy, narzędzi bazodanowych i poleceń SQL. Z tych dwóch podejść zgadzam się z poglądem, że EF jest właściwszym podejściem bo po prostu dla przypadku analizy projektu bazy w EF zawsze można napisać własny kod, niezależny od bazy SQL i wstrzyknąć go zamiast tego do czego ma się zastrzeżenia. ;-)

Jeżeli więc mowa o projektach optymalizacyjnych to skłaniam się ku myśleniu w kategoriach używania wielu modeli. Dla każdego przypadku można będzie wybierać jak najlepszy model, decydować jakie tabele, widoki, procedury składowane zamapować. EF DB first jawi się chyba jako punkt wyjścia, tym bardziej, że wypada jeszcze znać co to za bazy, jakie przechowują dane, jak jest z DRM. Po prostu tak apriori trudno być Duchem Świętym by wiedzieć jakie rozwiązanie będzie najlepsze. Dodatkowo jeżeli bazy mają zawierać treści multimedialne to Silverlight (Silverlight WCF) wydaje się trafnym podejściem.

Kto powiedział, że musi być jeden model? Przecież wszystkiego nie ogarnie się jednym kawałkiem kodu. ;-)))
Tomasz Maciąg.:
U nas najlepszym rozwiązaniem okazuje się być tworzenie contextu L2S
Hmm .. ale wobec aktualnych decyzji Microsoft o nie rozwijaniu Linq2SQL o tym, że to podejście nie jest przyszłościowe mówi się od dawna. Tym bardziej, że to do Linq To EF nowych funkcjonalności przybywa. ;-)
Tomasz M.

Tomasz M. never go full
retard!

Temat: [Poszukiwany] Fachowiec Entity Framework

Marek K.:
ale wobec aktualnych decyzji Microsoft o nie rozwijaniu Linq2SQL o tym, że to podejście nie jest przyszłościowe mówi się od dawna. Tym bardziej, że to do Linq To EF nowych funkcjonalności przybywa. ;-)

No i co z tego, skoro nadal spora grupa ludzi używa, a sam L2S jest lekki, prosty i przyjemny. Poza tym na tyle "skończony", że w zasadzie niewiele więcej potrzeba - a jak potrzeba, to się samemu dorzeźbi.

Temat: [Poszukiwany] Fachowiec Entity Framework

Jak się umie korzystać z ORM i łączyć go z widokami/prockami, to będzie dobrze. 500 tabel? Średni system. Używam NH w większym :) Obiekty - do pisania do bazy. "bulki" do szybkiego pisania. Widoki=>obiekty do "złożonego" czytania. Podejście wyłącznie code-first (NClass, EA i inne)i niech NH generuje DDL. Widoki zostawić specom od DB. Niech też mają wgląd w generowany SQL (NH jest cwany m.in. w zakresie joinow i existow). Dużo czytać, dużo eksperymentować. Nie wiem jak w EF ale NH jest bardzo elastyczny. Będzie dobrze. Marek ma rację.

Pozdrowienia z gór :)
Marek Kubiś

Marek Kubiś programista c#

Temat: [Poszukiwany] Fachowiec Entity Framework

Tomasz M.:
Marek K.:
ale wobec aktualnych decyzji Microsoft o nie rozwijaniu Linq2SQL o tym, że to podejście nie jest przyszłościowe mówi się od dawna. ;-)
No i co z tego, skoro nadal spora grupa ludzi używa, a sam L2S jest lekki, prosty i przyjemny. Poza tym na tyle "skończony", że w zasadzie niewiele więcej potrzeba - a jak potrzeba, to się samemu dorzeźbi.
Nie podważam, bo i sam lubię ;-))) ale narzędzia informatyczne umierają inaczej niż ludzie. Nie ma tak, że środowisko programistyczne odchodzi na zawsze, staje się całkowicie niedostępne tak jak człowiek. Jak pokazuje dotychczasowa historia rozwoju inżynierii oprogramowania, kiedy przestaje się coś rozwijać, to tak po prostu właściwie nie wiadomo kiedy, wypada zabrać się za przepisywanie kodu na nową platformę. ;-( Warto być tego świadomym kiedy rozpoczyna się nowy projekt i podjąć decyzję tak by nie mieć później do siebie pretensji, że nie pomyślało się o tym wcześniej. Tylko lub aż tyle. ;-)

Następna dyskusja:

Entity Framework - Reposito...




Wyślij zaproszenie do