Pare pytan do EntityFramework

To moje pierwsze zetkniecia z EF dlatego od razu nasuwaja mi sie pierwsze pytania, na ktore na razie nie znalazlem odpowiedzi w internecie ani w przykladach uzycia EF w przykladowych projektach.

1. Wygodniej mi zaczynac od ModelFirst a nie od Bazy, przy tworzeniu klas w ModelFirst moge umeiszczac w klasach tylko wlasciwosci. Jak moge potem umeiszczac metody w tych klasach ewentualnie modyfikowac settery w utworzonych wlasciwosciach w automatycznie generowanym pliku Model.designer.cs?

Przyklad: Klasa ZelcenieProdukcyjne, ma pola m.in: iloscZadana, StatusZlecenia, iloscZrealizowana
chcialbym w setterze pola iloscZrealizowana w przypadku gdy ta ilosc zrowna sie z ilosciaZadana zmienic status zlecenia z "W toku" na "Zakonczone". Nie wiem jeszcze o co chodzi w podejsciu CodeFirst ale czy takie podejscie zalatwiloby moj tok rozumowania i pogodziloby sie z EF? Czy moze atrybut "partial" w klasach generowanych przez EF to slowo klucz?

2. Jezeli spodobala mi sie organizacja kodu we wzorcu MVP w Winforms to Modelem w tym wzorcu moze byc model EF? Jezeli z programu ma korzystac kilka osob o roznych uprawnieniach, jednoczesnie to czy to dobre polaczenie MVP+EF?

3. Czy styl klasy tworzonej w generatorze ModelFirst (same wlasciwosci) to wlasnie klasy POCO? Mam problem z doczytaniem czym jest POCO?

Jeżeli czytałes definicję o POCO z wikipedii to nie jest ona do końca prawidłowa.
POCO znaczy tylko tyle, że klasy POCO nie są zależne od żadnego zewnętrznego frameworka, a korzystają jedynie z mechanizmów platformy .NET.
POCO może składać się tylko z getterów, setterów, ale nie musi.
Jeżeli chcesz aby twoje obiekty, które zapisujesz w bazie posiadały logikę biznesową i były klasami POCO -> Entity Framework Code First

Varran napisał(a):

1. Wygodniej mi zaczynac od ModelFirst a nie od Bazy, przy tworzeniu klas w ModelFirst moge umeiszczac w klasach tylko wlasciwosci. Jak moge potem umeiszczac metody w tych klasach ewentualnie modyfikowac settery w utworzonych wlasciwosciach w automatycznie generowanym pliku Model.designer.cs?
   [...] Nie wiem jeszcze o co chodzi w podejsciu CodeFirst ale czy takie podejscie zalatwiloby moj tok rozumowania i pogodziloby sie z EF? Czy moze atrybut "partial" w klasach generowanych przez EF to slowo klucz?

CF to lepsze podejście, w zasadzie sprowadza się do tego, że zamiast wyklikiwać encje piszesz je sobie jako klasę. Zaleta jest taka, że obchodzisz problem który napotkałeś ;)
Jeżeli jednak chcesz spróbować podejścia Model First - tak, partial będzie dobrym rozwiązaniem. Szukaj w google pod Model First Partial Buddy Class (to ostatnie to potoczna nazwa na takie klasy uzupełniające z tego co pamiętam).

Varran napisał(a):

2. Jezeli spodobala mi sie organizacja kodu we wzorcu MVP w Winforms to Modelem w tym wzorcu moze byc model EF? Jezeli z programu ma korzystac kilka osob o roznych uprawnieniach, jednoczesnie to czy to dobre polaczenie MVP+EF?

Nie powinny to być encje.

na razie mam wstepny prototyp "minisystemu" dzialajacy bez podlaczenia do bazy, na danych przykladowych generowancyh z kodu dlatego czytam o codefirst, ogladam tutoriale na YT, jak rusze z CodeFirst EF to pewnie zadam kolejna porcje pytan, na razie dzieki :)

u mnie podejście przy tworzeniu programów bazodanowych jest takie:
WebForms - database first
MVC - code first

Varran napisał(a):

2. Jezeli spodobala mi sie organizacja kodu we wzorcu MVP w Winforms to Modelem w tym wzorcu moze byc model EF? Jezeli z programu ma korzystac kilka osob o roznych uprawnieniach, jednoczesnie to czy to dobre polaczenie MVP+EF?

Częściowo tak. Model z MVP to logika biznesowa, której częścią jest warstwa dostępu do danych, czyli model EF.

CW napisał(a):

u mnie podejście przy tworzeniu programów bazodanowych jest takie:
WebForms - database first
MVC - code first

Czemu tak? Moim zdaniem to powinno zależeć od tego, czy baza danych już istnieje, czy nie, ewentualnie od jej wielkości.

Chcę się pytaniami dołączyć na temat Entity, również to ćwiczę tylko, że z MVC

1. Czy w praktyce ktoś stosuje podejście ModelFirst?
2. Co wg Was jest praktyczniejsze ADO.NET czy Entity? W życiu zawodowym czego więcej używacie?

1. Tak, stosuje się często. Przyczyną jest chociażby to, że w wielu firmach stosuje się jeszcze dziewiętnastowieczne podejście polegające na zaprojektowaniu bazy najpierw, a dopiero potem aplikacji. Albo po prostu dopisuje się aplikację do już istniejącej bazy.

2. ADO.NET to albo ręczne klejenie zapytań (co jest dobre w prostych zastosowaniach, pisaniu narzędzi pomocniczych, albo tam, gdzie zależy na wydajności), albo użycie starożytnych DataSetów (które nie są dobre w żadnym przypadku), EF jest przynajmniej obiektowe, więc jest lepsze dla typowych aplikacji użytkowych.
   A w poważnych projektach i tak używa się NHibernate.