Struktura aplikacji WPF

Question

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 :)

Answer 1

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

Comments

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. 

 

  

---

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

---

oki dzięki za pomoc w takim razie :)