Struktura aplikacji WPF

pytanie zadane 31 sierpnia 2016 w C# przez achilles147 Dyskutant (9,580 p.)

Cześć,

Jestem w trakcie tworzenia dosyć sporej aplikacji opartej na WPF. Mam nie duże doświadczenie w tym frameworku i chciałbym się was zapytać o to jak powinna wyglądać struktura solucji w takim projekcie. Ogólnie rzecz biorąc sam WPF narzuca wykorzystywanie architektury MVVM ( podział aplikacji na warstwy). Moje pytanie więc jest takie :

Czy solucja taka powinna składać się z 2 projektów ( warstwy prezentacji i warstwy logiki) czy też tych projektów powinno być więcej. W aplikacji mojej będzie wykorzystywane także połączenie z bazą danych za pomocą Entity Framework. Być może w takim razie powinno się dodać kolejny projekt?. Szczerze mówiąc zupełnie się na tym nie znam, jeżeli ktoś ma jakieś większe doświadczenie prosiłbym o jakieś rady :)

1 odpowiedź

odpowiedź 4 września 2016 przez Thomas Frost Bywalec (2,540 p.)
wybrane 5 września 2016 przez achilles147

Najlepsza

Cześć,

Powinieneś poczytać na temat MVC i zastosować się właśnie do tego.

Możesz trzymać modele, view i controler w tym samym projekcie - najważniejsze aby było to odpowiednio podzielone za pomocą folderów. Jeśli jednak chcesz stworzyć część kodu jako DLL, to ta dll'ka powinna być w osobnym projekcie (każda dll'ka osobno).

Odradzam ci używanie Entity Framework'a do połączenia się z bazą danych z tak małą wiedzą. Jako alternatywę polecam ściągnięcie biblioteki MySQL do łączenia z bazą danych z NuGet'a lub użycie MicrosoftSQL.

Powinno to wyglądać tak:
Modele: kontenery na dane, również te dla danych ściągniętych z bazy danych lub wrzucanych do bazy danych.
View: WPF - tylko i wyłącznie prezentacja danych.
Controler: logika - co i jak ma działać, pobieranie i wrzucanie do bazy danych, wyrzucanie gotowych danych do View oraz odbieranie eventów od View, kontrola poprawności danych.
Repositories: zawiera się w "Controler" i polega na manipulacji modelami (tj. zmiana danych trzymanych w modelach i kontrola, zgodności danych wrzucanych do modeli), operacje na modelach.

Ogólnie powinieneś podzielić problem na jak najwięcej małych problemów (małych klas). Pamiętaj jedna metoda wykonuje jedną operację abstrakcyjną, a jedna klasa rozwiązuje jeden problem (np. pierwsza klasa łączy się z bazą danych, druga klasa kontroluje przepływ danych do i z bazy danych, trzecia klasa zawiera obie klasy i wykonuje już zadania bardziej ogólne - tj. inicjalizuje połączenie za pomocą klasy pierwszej i kiedy ją zawołamy wrzucany dane do bazy lub wyciąga z bazy za pomocą klasy drugiej).

Pozdrawiam,
Tomek

komentarz 5 września 2016 przez achilles147 Dyskutant (9,580 p.)

Dzięki za odpowiedź :).

Co do niej, to chodziło mi bardziej o jakieś dobre praktyki rozłożenia takiego kodu. Tak jak sam napisałeś.

Jeśli jednak chcesz stworzyć część kodu jako DLL, to ta dll'ka powinna być w osobnym projekcie (każda dll'ka osobno).

tutaj chodziło mi o to jaka część kodu dokładnie:) ( czy wydzielić widoki i stworzyć dllke zawierającą warstwę prezentacji, a następnie to samo zrobić np z modelami?)

Odradzam ci używanie Entity Framework'a do połączenia się z bazą danych z tak małą wiedzą

Szczerze mówiąc nie wiem czemu tak zakładasz:) EF jest całkiem w porządku i daje możliwości tworzenia encji biznesowych a co za tym idzie w późniejszym etapie aplikacji np. śledzenia ich stanu.

komentarz 5 września 2016 przez Thomas Frost Bywalec (2,540 p.)

Cześć,

DLL'ki służą tylko do warstwy logicznej (np. rysowanie kształtów na bitmapie), natomiast warstwę prezentacji trzymamy zawsze w swojej aplikacji. Tworzysz wszystkie widoki, jakie będą w twojej aplikacji, natomiast modele i duża część logiki (nie cała - konkretna implementacja logiki w danej aplikacji/widoku powinna również znajdować się w twojej aplikacji) może znajdować się w DLL.

Jak podzielić wnętrze aplikacji dobrze obrazuje to ten diagram: https://pl.wikipedia.org/wiki/Model-View-Controller#/media/File:Mvc_classes_pl.svg

Bardzo ciężko odpowiedzieć na twoje pytanie, ponieważ każdy problem jest inny. O ile istnieją pewne ramy, jak to się robi, to jednak zawsze się te rozwiązania/implementacje różnią do siebie.
Po prostu musisz zacząć i liczyć się z tym, że wiele razy będziesz zmieniać strukturę kodu (refaktoryzacja), co jest normalne, ponieważ wraz z doświadczeniem oraz sposobem programowania (np. tworzy się kod, który się działa, a dopiero wtedy się go porządkuje).
Nie dam niestety rady napisać konkretów, bo albo sam wszystkie nie wiem, albo zajęłoby to bardzo dużo czasu (nic nie zastąpi dobrej książki np. "Czysty Kod").

A co do ET, miałem na myśli, że może być dla ciebie za trudny, jeśli nie masz doświadczenia w ET, zwracam uwagę że warstwa abstrakcji jaką zapewnia MVC, jest już ciężka do debugowania, natomiast ET jest poziom wyżej w abstrakcji.

Pozdrawiam,
Tomek