MVCS - Model View Store Store

Niedawno postanowiłem zacząć uczyć się programowania na iOS i w tym celu czytam Programowanie na iOS: The Big Nerd Ranch Guide . W książce autorzy opisują wzorzec projektowy MVCS - Model-View-Controller-Store , podstawową ideą jest to, że ponieważ wiele aplikacji korzysta z wielu zewnętrznych źródeł danych, utrzymywanie logiki żądań w kontrolerze może być bardzo nieporządne, zamiast tego autorzy zaproponuj przeniesienie całej logiki żądania ze sterownika do osobnego obiektu.

W skrócie, aby zacytować książkę

Model-View-Controller-Store umieszcza logikę żądań w oddzielnym obiekcie, a my nazywamy ten obiekt magazynem (rysunek 28.4). Korzystanie z obiektu sklepu minimalizuje nadmiarowy kod i upraszcza kod, który pobiera i zapisuje dane. Co najważniejsze, przenosi logikę radzenia sobie z zewnętrznym źródłem do uporządkowanej klasy z jasnym i skoncentrowanym celem. Dzięki temu kod jest łatwiejszy do zrozumienia, co ułatwia utrzymanie i debugowanie, a także udostępnianie innym programistom w zespole.

I

Fajną rzeczą w sklepach asynchronicznych jest to, że chociaż wiele obiektów wykonuje wiele pracy w celu przetworzenia żądania, przepływ żądania i jego odpowiedź znajdują się w jednym miejscu w kontrolerze. Daje nam to korzyść z kodu, który jest łatwy do odczytania, a także łatwy do modyfikacji.

Chciałem dowiedzieć się więcej na temat tego wzoru i zobaczyć, co inni mogą o nim powiedzieć, ale podczas wyszukiwania w Internecie jedyne odniesienia, jakie mogłem znaleźć, to ta sama książka (czy wzór może być znany pod inną nazwą?).

Wydaje mi się, że logika autora ma sens i wydaje się logicznym rozszerzeniem normalnego wzorca MVC, ale być może dlatego, że tak naprawdę nie mam dużego doświadczenia ze wzorcem MVC w praktyce (poza próbą rozwoju iOS mam rodzaj używanych MVV z backbone.js (to znaczy, jeśli uważasz to za MVC )).

Miałem nadzieję, że być może ktoś z większym doświadczeniem rzuci nieco światła na to, czy są jakieś oczywiste wady / problemy ze wzorem MVCS , których mi brakuje.

„Sklep” w przypadku wzorców projektowych MVCS skłania się ku logice przechowywania. W przypadku iOS jest to zwykle implementacja Core Data. Jeśli utworzysz szablon oparty na danych podstawowych w Xcode, zobaczysz aspekt „Store” tego wzorca projektowego schowany w klasie AppDelegate.

Aby przenieść to na wyższy poziom, często tworzę klasę menedżerów singletonów, która obsługuje konfigurowanie stosu danych podstawowych i zajmuje się wszystkimi pobieraniem / zapisywaniem związanym ze stosem. Jak wspomniałem w cytacie, bardzo łatwo jest nie tylko wywoływać te metody, ale dostosowywać je w razie potrzeby, w przeciwieństwie do zapisywania / pobierania połączeń w dowolnym miejscu w różnych kontrolerach widoku.

Paradygmat „Store” nie ogranicza się jednak do Core Data. Twój sklep może być po prostu usługą internetową. Być może masz klasę, która współdziała z Facebookiem, Twitterem, Yelp lub innym interfejsem API opartym na REST. Zauważyłem (i podobnie podążam za trendem), że tego rodzaju klasy również nazywają się Menedżer. Bardzo dosłownie zarządzają wszystkimi wewnętrznymi szczegółami, dzięki czemu twoje inne klasy mogą po prostu wprowadzić lub wydostać dokładnie to, czego potrzebują.

Jeśli chodzi o oczywiste wady lub problemy z tym wzorcem projektowym ... Tak jak w przypadku każdego wzoru wzorcowego, najbardziej rażącym problemem jest upewnienie się, że projekt został skonfigurowany w taki sposób, aby ominął go paradygmat. Zwłaszcza w przypadku wzoru, który jest dla ciebie nowy, może to być czasem najtrudniejsza część. Zaletą podziału logiki „Store” na własną klasę jest to, że znacznie ułatwia utrzymanie kodu.

„Sklep” w tym kontekście brzmi bardzo podobnie do repozytorium lub usługi . W takim przypadku jest to niezwykle powszechny wzór. Wady / problemy będą się różnić w zależności od implementacji i dziedziny problemów.

Na poziomie ogólnym wydaje się, że książka używa „Store” do reprezentowania poziomu logiki biznesowej + poziomu logiki pobierania danych, która obsługuje zestaw danych, które mogą, ale nie muszą być częścią twojej aplikacji.

Na przykład zawinięcie interfejsu API Twittera w „Sklepie” to dobry sposób na podzielenie tej logiki na przedziały.

Po dalszych przemyśleniach
Korzystając z tej definicji MVC (która moim zdaniem jest dość trafna), „Sklep” jest tak naprawdę podzbiorem modelu. Określenie, czy jest to rozszerzenie MVC, czy wzorzec pobierania danych, nie jest szczególnie przydatne. W efekcie wyglądają jak ten sam kod.

Podsumowując, myślę, że będzie dobrze postępować zgodnie z sugestią, którą sugerują (wydaje się ogólnie rozsądna).