Gdzie mam umieścić żądanie API w MVC?

Buduję aplikację internetową przy użyciu wzorca MVC. Zgodnie z tego rodzaju architekturą możemy zobaczyć, że wszystkie metody używane do interakcji z bazą danych są zaimplementowane w modelu .

Ale co się stanie, jeśli będę musiał zadzwonić do usługi udostępnianej przez innych w sieci? Na przykład chciałbym uzyskać dostęp do interfejsu API Facebooka, aby uzyskać dostęp do wszystkich obserwujących moją stronę, więc gdzie umieszczam te metody?

Oczywiście widok nie jest dobrym pomysłem, ponieważ ten moduł jest poświęcony prezentacji, kontroler nie powinien być wykorzystywany do pobierania danych, ale model jest zwykle przeznaczony tylko do interakcji z bazą danych.

Czy możesz mi coś o tym powiedzieć? I proszę, czy możesz mi powiedzieć, jeśli popełniam błędy w architekturze MVC?

Model nie ogranicza się do interakcji z bazą danych, model jest odpowiedzialny za pobieranie i manipulowanie danymi.

Tak więc, twoim zdaniem i kontrolerowi, nie powinno to mieć znaczenia, jeśli dane pochodzą z bazy danych lub z usługi internetowej, a nawet są całkowicie losowe, dlatego powinieneś to zrobić w modelu.

MVC to wzorzec prezentacji, który oddziela tylko różne warstwy reprezentacji.

Nie oznacza to, że ten model musi być jednolitym bałaganem kodu spaghetti. Sam model może być warstwowy, ale administrator nie powinien wiedzieć, skąd pochodzą dane.

Metoda publiczna w twoim modelu może mieć następującą strukturę (pseudo-kod), którą może wywołać kontroler:

public MyDataClass getData(int id) {
    WebServiceData wsData = WebService->getData(id);
    DatabaseData dbData = ORM->getData(id);
    return new MyDataClass(wsData, dbData);
}

WebServicei ORMmoże być konieczne wystąpienie interfejsów, które można zastąpić próbnymi metodami za pomocą wstrzykiwania zależności, ale kontrolery i widoki nie muszą się zmieniać w celach testowych.

Istnieje powszechne (umyślne?) Nieporozumienie dotyczące tego, czym są M, V i C. Nie o rolach, które przyjmują, ale jakie są .

W oryginalnej definicji graficznego interfejsu użytkownika MVC były to moduły . Zazwyczaj aplikacja zawierała kilka z nich, czasami pracując w trojaczkach, czasami mając różnorodne widoki i modele, które kilka kontrolerów mogło łączyć i dopasowywać.

We frameworkach sieciowych, OTOH, są one zwykle postrzegane jako warstwy , gdzie są tylko jedną z nich i zajmują się głównie pokryciem pewnego poziomu pobocznego abstrakcji: „warstwa modelu abstrakcji bazy danych”, „warstwa widoku implementuje prezentację”, „kontroler warstwa przetwarza dane wprowadzone przez użytkownika ".

Więc powiedziałbym, że masz już to model, dedykowany do interakcji z bazą danych, a teraz po prostu trzeba utworzyć inny model do czynienia z source API. Jeśli uczynisz je możliwie jak najbardziej podobnymi, większość kontrolera i kodu widoku może bezproblemowo współpracować z dowolnym modelem.

Częściową trudnością przy jakiejkolwiek dyskusji na temat MVC jest to, że różne grupy kooptowały go, aby oznaczać różne rzeczy. Implementacja MVC zastosowana, powiedzmy, w aplikacji Rails, byłaby prawie nie do poznania dla kogoś, kto pisze aplikację Swing. W zakresie, w jakim MVC jest nadal dobrze zdefiniowaną rzeczą, jest to raczej zbiór zasad przewodnich (oddzielenie podstawowej aplikacji od jej wizualnej reprezentacji, zapewnienie elastycznych mechanizmów umożliwiających połączenie tych dwóch elementów), które można wdrożyć w różnych sposoby

Rzeczywiście istnieje tendencja do nadawania innym projektom pochodzącym z MVC różnych nazw (patrz artykuł Martina Fowlera, aby o tym dyskutować), a nawet rezygnacji z precyzyjnego nazewnictwa - na przykład AngularJS opisuje się jako Model-Widok-Cokolwiek struktura.

Trudno więc odpowiedzieć, nie wiedząc, z którą wersją „MVC” pracujesz. Jednak żądanie API zwykle stanowiłoby część podstawowej aplikacji (część, która nie powinna ulec zmianie, jeśli zdecydujesz się użyć innej reprezentacji wizualnej), która w wielu implementacjach byłaby zawarta całkowicie w modelu.

Tutaj model jest opisany w następujący sposób:

Model przechowuje dane, które są pobierane do kontrolera i wyświetlane w widoku. Ilekroć następuje zmiana danych, jest ona aktualizowana przez kontrolera.

Powiedziałbym, że kontroler zawiera logikę wywoływania usługi lub wywołuje oddzielny Serviceobiekt. Jeśli usługa jest osobna, możesz łatwiej tworzyć testy, powiedzmy, jeśli nie jest możliwe połączenie z usługą za pośrednictwem sieci, niektóre TestServicemogą udzielać odpowiedzi Servicelokalnie.

Sprawdź również tę odpowiedź, która sugeruje, że kontroler wywołuje usługę.

Twój model nigdy nie powinien zawierać żadnego faktycznego kodu i powinien być postrzegany jako komunikat lub struktura używana do zarządzania treściami manipulowanymi przez kontroler i wyświetlanymi przez widok.

Twój kontroler powinien być odpowiedzialny za kontaktowanie się z wszelkimi interfejsami API, bazami danych, usługami itp. ... żądaniem zmiany i zarządzaniem niezbędnymi aktualizacjami modelu.

Cała siła wzoru MVC polega na tym, że oddziela on logikę (kontroler) od widoku i stanu (model). W ten sposób masz teraz gwarancję, że tylko kod w kontrolerze może wywoływać skutki uboczne, ponieważ widok i model po prostu nie mogą wprowadzać zmian.

Pozwala także na lepsze ponowne wykorzystanie kodu, ponieważ model może być współużytkowany przez różne kontrolery i widoki.

Może być daleko, ale tak myślę o WebApps i pracy ze [złożonymi] zdalnymi API w wielu przypadkach:

Zrobiłbym to klasę (tj. Bibliotekę metod ograniczania danych) zamiast modelu (tj. Stos funkcji ograniczania danych). Wygląda na to, że działałby bardziej przejrzysto, bardziej agnostycznie względem logiki / schematu, i można go używać wszędzie, bez ładowania-> wywoływania samego modelu / kontrolera za każdym razem, gdy chcesz go użyć. Logika jest nadal oddzielona, ​​punkt danych jest nadal elastyczny, i wydaje się bardziej otwarty na interoperacyjność w dziwnych przypadkach, takich jak układanie klientaAJAX-> appJSON-> appLIB-> remoteAPI-> remoteJSON itp., Aby pośrednio sondować punkt końcowy.