Wątek przeniesiony 2015-01-21 12:21 z C# i .NET przez somekind.

mvvm, api & patterns

0

Witam,
piszę aplikację w WPF/MVVM. Komunikuje się ona z serwerem (nie ważne co robi serwer).
Do komunikacji używam dedykowanej biblioteki zawierającej API.
Zawiera kilka klas z funkcjonalnościami, a każda klasa implementuje publiczny interfejs.

Zgodnie z tymi wszystkimi patternami powinienem:
podejście 1:
wstrzyknąć gotowe interfejsy i ich implementacje do kontenera IoC, a następnie mapować zwracane obiekty tam gdzie tego potrzebuje

podejście 2:
napisać własny interfejs z własną implementacją -> wrapper na istniejące API -> i te nowo stworzone interfejsy i implementacje wstrzyknąć w kontener

Proszę o pomoc w wyborze lub zaproponowanie innego, wartego rozważenia, podejścia

0

"wstrzyknąć gotowe interfejsy i ich implementacje do kontenera IoC"
właściwie to:

**zarejestrować **istniejące interfejsy i ich implementacja w kontenerze IoC :-)

0

To może tak:
Macie za zadanie zrobić klienta forum aplikacji 4programmers.net
Do tego dostajecie bibliotekę .NET, która zawiera wszystkie funkcjonalności

Powiedzmy, że biblioteka zawiera klasę ForumManager implementującą interfejs IForumManager.
Udostępnia ona metodę GetTopics, która zwraca kolekcję obiektów klasy Topic (klasa Topic nie implementuje interfejsu INotifyPropertyChanged)

Co zrobilibyście teraz?

  1. Rejestrujecie w kontenerze klasę ForumManager
  2. Piszecie własną klasę, w której korzystacie z klasy ForumManager, i ta nowo utworzona klasa jest rejestrowana

Co jest lepsze dla testów?
Co jeśli za jakiś czas klient wpadnie na pomysł, że aplikacja ma obsługiwać nie tylko jedno forum, ale wiele?

Czy tworzenie dodatkowej warstwy to nie jest przerost formy nad treścią?

0

Może jakakolwiek sugestia, link?

2

W ogólności tworzenie niepotrzebnej warstwy to przerost formy nad treścią i konieczność utrzymywania dodatkowego kodu. Ale trzeba się też zastanowić, jakie są szanse, że klient zażąda obsługi więcej niż jednego forum? Jeśli duże, to mimo wszystko dodałbym ten wrapper. Jeśli małe, to nie, najwyżej, jeśli klientowi się kiedyś coś odwidzi, to wtedy się wprowadzi dodatkową warstwę.

Gdzieś trzeba znaleźć kompromis między YAGNI, a skomplikowaniem architektury i elastycznością wprowadzania zmian.

0

Dzięki za odpowiedź!
Zacząłem od wrappera i kod zrobił się bardzo duży, stąd moje pytanie.

Poza tym aplikacja do obsługi konkretnego forum i dowolnej ilości forum, to dwie różne aplikacje, zgadzasz się? Czyli nawet jak na dzień dzisiejszy chciałbym zrobić to tak, żeby można było dołożyć obsługę innego forum, to sam wrapper na by nie wystarczył. Należałoby zrobić interfejsy dla zupełnie nowej logiki biznesowej. Zgadza się?

0

Zależy jak bardzo te fora różnią się swoją funkcjonalnością. Ale zapewne masz rację, że nie da się napisać uniwersalnego wrappera. Ale może też nie muszą być tworzone oddzielne aplikacje, a jedynie nowe moduły w jednej aplikacji. Trudno to określić bez dokładnych danych na ten temat.

0

Ok. Dzięki za odpowiedź. Nowe forum to również nowa wycena projektu:)
Potrzebowałem informacji od kogoś, żeby mi powiedział że wrapper nie zawsze ma sens - nie mogłem już patrzeć na zawiłość mojego kodu:)

0

Hmm... A jak będę potrzebował nowej metody, dajmy na to GetTopicByUsername, to nim dostawca dostarczy zaktualizowane API, to mógłbym w moim wrapperze dopisać taką metodę i ją mockować. Jeżeli kontener będzie miał zarejestrowane klasy API a nie wrappera to będzie to znacznie utrudnione...

0

No tak, jeśli potrzebujesz abstrakcji nad API, a nie tylko użycia API, to musisz tę abstrakcję napisać.

1 użytkowników online, w tym zalogowanych: 0, gości: 1