Proszę o ocenę kodu mojej pierwszej aplikacji WPF korzystającej z wzorca MVVM: https://github.com/mateuszradny/NetTalk
Starałem się zachować dobre nawyki i mam nadzieje, że dobrze zrozumiałem koncepcję MVVM w połączeniu z WPF.
Jest to prosty komunikator klient-serwer napisany w ramach przedmiotu na zaliczenie (chciałem poświęcić na to max tydzień czasu i tak się stało)
1
2
Tak na pierwszy rzut oka: jak na projekt studencki na zaliczenie to jest to naprawdę fajnie zrobione uważam! Nie jeden student chciałby tak pisać. Masz serwisy zarządzające komunikacją, masz niewielkie viewmodele (pamiętaj, przerośnięte vm z logiką biznesową to zuo), masz kontener IoC - żyć nie umierać. Widać, że rozumiesz koncepcje MVVM.
Tak już z technicznych uwag to może niepotrzebnie bawisz się w komunikację na poziomie socketów przez co trochę komplikujesz sobie implementację. Są w .Net'cie gotowe klasy takie jak TcpClient czy TcpListener i zabawa z nimi jest trochę prostsza, bo na wyższym poziomie abstrakcji. EDIT: Widzę, że serwer jest napisany w C++ więc może nie miałeś innego wyjścia ale... poradziłeś sobie i to też bardzo dobrze świadczy!
No i trochę nie podoba mi się wstrzykiwanie VM przez konstruktor do innego VM np tutaj: public ContactsViewModel(ChatViewModel chatViewModel, IClientService clientService). Przekaż w serwisie dane odpowiednią klasą, a później składaj model widoku.
Ja bym tam jeszcze wrzucił warstwę szyfrująca dane np wymieniasz się kluczami publicznymi z serwerem. Kluczem publicznym serwera szyfrujesz klucz dla algorytmu symetrycznego, którego używasz do zaszyfrowania wiadomości dla drugiej strony. Paczkę: zaszyfrowany klucz, zaszyfrowana wiadomość pchasz do serwera i masz bezpieczną komunikację, ponieważ serwer wie jak zrobić dekryptarz ale... to już tak w ramach offtopic'a, bo fajnie się bawić kiedy serwer i klient są pisane w jednym języku :) Polecam, bo to ciekawy temat.
Aha: Model (model i serwisy) możesz zrobić jako osobny projekt w solucji, a do głównego programu dodawać skompilowaną DLL'kę. Jest to wysoce zalecane. To plus unit testy i masz naprawdę sprawnie działającą solucję
Aha 2: Trzymaj sobie ten projekt i rozwijaj go, a będziesz miał fajną rzecz do pokazania np. podczas rozmowy o pracę. Dodaj do projektu przechowywanie historii rozmów np. w jakiejś bazie danych. Będziesz musiał rozbudować projekt zawierający model aplikacji i bardzo wiele się dzięki temu nauczysz. Wiem z autopsji, że warto. Nawet jak w przyszłości nie będziesz pisał w WPF, to backend będziesz miał obcykany.
Aha 3: Wiesz... do bazy danych możesz użyć jakiegoć ORM'a typu nHibernate i rozwój gwarantowany :)
Aha 4: Wywal ten serwer w C++ i przepisz go na C#, a będziesz miał dużo prostszą komunikację i implementację wszystkiego o czym wyżej napisałem w ramach samorozwoju.
Aha 5: A teraz na sam koniec zasmucę Cię. Niestety technologie desktopowe są dzisiaj mocno w odwrocie na rzecz tfu! webowych aplikacji.
To tak na pierwszy rzut oka.
0
grzesiek51114 napisał(a):
Tak już z technicznych uwag to może niepotrzebnie bawisz się w komunikację na poziomie socketów przez co trochę komplikujesz sobie implementację. Są w .Net'cie gotowe klasy takie jak
TcpClientczyTcpListeneri zabawa z nimi jest trochę prostsza, bo na wyższym poziomie abstrakcji. EDIT: Widzę, że serwer jest napisany w C++ więc może nie miałeś innego wyjścia ale... poradziłeś sobie i to też bardzo dobrze świadczy!
Serwer w C++ oraz korzystanie z socketów było wymuszone przez prowadzącego.
No i trochę nie podoba mi się wstrzykiwanie VM przez konstruktor do innego VM np tutaj:
public ContactsViewModel(ChatViewModel chatViewModel, IClientService clientService). Przekaż w serwisie dane odpowiednią klasą, a później składaj model widoku.
Mógłbyś to rozwinąć?
Aha: Model (model i serwisy) możesz zrobić jako osobny projekt w solucji, a do głównego programu dodawać skompilowaną DLL'kę. Jest to wysoce zalecane. To plus unit testy i masz naprawdę sprawnie działającą solucję
Tak robię w większych projektach :)
Aha 4: Wywal ten serwer w C++ i przepisz go na C#, a będziesz miał dużo prostszą komunikację i implementację wszystkiego o czym wyżej napisałem w ramach samorozwoju.
Pomyślę nad tym, może napiszę klienta webowego dla frajdy :)
Dzięki za wskazówki!
0
No i trochę nie podoba mi się wstrzykiwanie VM przez konstruktor do innego VM np tutaj: public ContactsViewModel(ChatViewModel chatViewModel, IClientService clientService). Przekaż w serwisie dane odpowiednią klasą, a później składaj model widoku.
Tworzysz klasę w modelu, która przechowuje dane. Obiekt takiej klasy przenosisz do jakiegoś serwisu i tam nim zarządzasz. Nie ma wtedy potrzeby wstrzykiwania go do konstruktora VM, ponieważ zostanie wstrzyknięty razem z serwisem. W serwisie obrabiasz i przygotowujesz dane czy co tam chcesz no i robisz sobie metodę albo gettera, który zwróci Ci przygotowany obiekt i taki obiekt opakowujesz dopiero dla widoku w ViewModelu. Zostałoby Ci wtedy tylko ContactsViewModel(IClientService clientService) - prościej i bez zbędnej zależności.