Prezentacja modelu - ten sam widok, różni prezenterowie

Question

Buduję jedną aplikację na Androida przy użyciu MVP i mam jedno pytanie dotyczące tego wzorca.

Załóżmy, że mam jeden ekran umożliwiający tworzenie nowej osoby. Ten ekran pokaże jeden EditText do wstawienia nazwy, drugi do nazwiska, jeden ImageView, aby pokazać wybrane zdjęcie, itp. To doprowadzi do jednego interfejsu View, zaimplementowanego przez Fragment. Będzie współpracować z jednym interfejsem Presenter, implementowanym przez inną klasę.

Dobrze.

Teraz mam kolejną funkcję: ekran do edycji edycji istniejącej osoby. Tak się składa, że ​​View dla tej funkcji jest identyczny z tym, który służy do tworzenia nowej osoby. Jednak Presenter jest inny. Rozpocznie się od załadowania istniejącej osoby z bazy danych, aby wstępnie wypełnić widok bieżącymi danymi, a czynność nad bazą danych po kliknięciu przycisku "zapisz" będzie aktualizacją zamiast wstawiania.

Uważam, że jest to przykład MVP , w którym jeden widok działa z różnymi implementacjami prezentera, aby uzyskać różne zastosowania:.

1. Czy uważasz, że to założenie jest poprawne, czy myślisz, że różne cechy powinien posiadać różne View i Presenter interfejsy?

2. Ponadto, jeśli bym ze wspólnym View i innym Presenters będzie realizacja View być wspólne lub prowadziłoby do tego samego interfejsu realizowanego przez dwóch klas? W praktyce widzę dwie opcje.

   • Mając tylko jeden Fragment realizacji View. W zależności od tego, czy użytkownik chce utworzyć nową osobę, czy zaktualizować istniejącą, Fragment powinien otrzymać i użyć innego prezentera.

   • Posiadanie dwóch Fragment s. Każda z nich tworzy instancję innego Presenter. Użyj kompozycji lub dziedziczenia, aby uniknąć replikacji kodu między dwoma fragmentami.

Co sądzisz lepiej jest robić w takich przypadkach?

Dzięki.

Answer 1

Napotkasz na tym, tworząc aplikację podobną do CRUD, używając wzorca MVP na Androida.

Można bardzo łatwo po prostu mieć jeden widok, tak długo, jak udokumentować dobrze w swojej klasie, że IMPL „Widok” dla dwóch różnych prezenterów, to „jest w porządku”

---

bym osobiście sugeruję utworzenie 2 widoków, jednego dla "tworzenia" i jednego dla "edycji" (mogą być one takie same (jak na razie), ale ich oddzielenie pokazuje, że są to różne rzeczy.)

Możesz łatwo zobaczyć sytuację w przyszłości (lub inną implikację tego wzorca), w której widoki "utwórz" i "edytuj" faktycznie mają różne interfejsy API. Lub nieco inne wizualne wskazówki, takie jak przycisk oznaczony "utwórz/dodaj" w jednym i "zaktualizuj" w innym.

Zrobiłbym osobiście klasę biblioteki widoku/pomocnika, z której oba widoki pobierają logikę. Powinno to pomóc w obniżeniu ogólnej wartości LoC, nawet jeśli tworzysz 2 klasy "widoku". Zaletą tego jest to, że łatwo zmieniasz widoki Tworzenie/Edycja bez martwienia się o wpływ na inne. (Myślę, że pliki z 2 widokami będą łatwiejsze do utrzymania na drodze, gdy wystąpi nawet "niewielka" różnica między tworzeniem/edytowaniem).