Usługa API MVC i RESTful

12

MVC jest dość proste. Istnieje model, kontroler i widok. Kiedy tworzymy stronę internetową, wszystko się łączy, gdy „ klient wysyła żądanie słowa kluczowego REST do serwera -> serwer dopasowuje żądany adres URL do działania kontrolera -> który następnie wywołuje model (y) do gromadzenia / przetwarzania danych, uzyskuje wynik -> i zwraca wynik z powrotem do klienta jako stronę HTML (widok) ”.

Co jeśli mówimy o czystej usłudze sieciowej RESTful API? Następnie przepływ z czymś w rodzaju „ klient wysyła żądanie słowa kluczowego REST do serwera -> serwer dopasowuje żądany adres URL do działania kontrolera -> który następnie wywołuje model (y) do gromadzenia / przetwarzania danych, uzyskuje wynik -> i zwraca wynik z powrotem do klienta w JSON '. Tak jak poprzednio, ale nie ma „widoku” ... a raczej wygenerowany JSON można traktować jako „widok”. W pewnym sensie korzystamy tylko z części MC MVC. Czy tak należy to zrobić? A może istnieją inne, lepiej dopasowane wzorce dla usługi tylko API zamiast MVC?

Szymon
źródło

Odpowiedzi:

21

MVC to paradygmat ze świata Smalltalk, który dotyczy tego, w jaki sposób systemy zorientowane obiektowo mogą mieć interfejsy użytkownika.

Wczesne frameworki internetowe przyjęły ogólną ideę (oddzielają logikę biznesową, logikę kontrolującą i logikę widokową) i stosują tę zasadę do struktury aplikacji. Wcześniej nie było rzadkością, że Bóg strasznie bałagan kodu generowania HTML wewnątrz obiektów domeny lub logiki biznesowej w szablonach HTML (pomyśl bardzo wcześnie PHP)

Chodzi o to, że oryginalny MVC ze świata Smalltalk nie jest tak naprawdę MVC w większości platform internetowych. Wyjście HTML nie jest tak naprawdę „widokiem” w tym sensie, że Smalltalk rozumiał ekran interfejsu użytkownika.

Jest to więc pierwszy powód, dla którego nie należy się odrywać od tego, czy prawidłowo śledzisz MVC. Prawie nic nie jest. Traktuj to mniej jako ścisły podział, a raczej wytyczną Hej, nie byłoby miło, gdyby nasze szablony HTML nie były pełne logiki biznesowej.

Po drugie, MVC jest tylko sposobem na uporządkowanie kodu po stronie serwera. To naprawdę nie ma nic wspólnego z REST / HTTP. REST dotyczy sposobu komunikacji klientów i serwerów. Nie ma znaczenia, czy reprezentacja, którą serwer wysyła do klienta, znajduje się w szablonie HTML, którego budowa wymagała dużo czasu za pomocą silnika szablonów, czy w obiekcie JSON, który był jednym wywołaniem w kontrolerze.

Jeśli nie uważasz, że Twój serwer potrzebuje warstwy „widoku”, która jest w porządku. Nadal będziesz czerpać korzyści z oddzielenia logiki biznesowej (tj. Modelu) od kontrolerów, które obsługują określone żądanie HTTP, nawet jeśli cały kontroler wywołuje wywołanie parsowania JSON dla jakiegoś obiektu i zwraca te dane.

Cormac Mulhall
źródło
Dokładnie to, co musiałem usłyszeć. Pochodzę ze świata twórców stron internetowych (wraz ze skryptami z jednym plikiem), więc nie widziałem, jak strukturyzowane są aplikacje internetowe na dużą skalę. System, który obecnie wdrażam, wykracza poza zwykłą aplikację internetową. Z tego, co przeczytałem do tej pory, tak naprawdę nie ma znaczenia, jak ustrukturyzujesz źródło aplikacji, głównym celem jest ułatwienie nawigacji i utrzymania. Wykorzystam koncepcje ze wzoru MVC do uporządkowania mojej aplikacji. Dzięki!
simon
@ wapno ... głównym celem jest ułatwienie nawigacji i utrzymania. Czy to nie zawsze jest celem?
Andy,
@David Packer, oczywiście, że tak =) Po prostu byłem zbyt przywiązany do koncepcji, pomijając rzeczywiste wykorzystanie tej koncepcji.
simon
1
Zapoznaj się z prezentacją Boba Martina na temat Czystej architektury, jeśli chcesz zobaczyć inny, potencjalnie lepszy sposób strukturyzacji aplikacji niż ten, który robi wiele frameworków internetowych.
Cormac Mulhall
9

Widok to warstwa odpowiedzialna za wyświetlanie informacji, które mogą być interpretowane przez użytkownika / klienta twojej aplikacji (nie oznacza to, że użytkownik musi być faktyczną osobą). JSON jest całkowicie poprawnym formatem warstwy widoku, komputery to rozumieją.

Tak długo, jak warstwa widoku publikuje informacje, które mogą być wykorzystane przez użytkownika do wpływania na modele w aplikacji, nie ma znaczenia, jak wygląda widok, nadal jest widokiem, warstwą działającą jako oprogramowanie pośrednie między użytkownikiem a systemem .

Andy
źródło
2

MVC jest dość proste.

Być może Martin Fowler nie zgodziłby się z tym :

Różni ludzie czytający o MVC w różnych miejscach biorą z niego różne pomysły i opisują je jako „MVC”.

Iść dalej...

Kiedy tworzymy stronę internetową, wszystko się łączy, gdy „klient wysyła żądanie słowa kluczowego REST do serwera -> serwer dopasowuje żądany adres URL do działania kontrolera -> który następnie wywołuje model (y) do gromadzenia / przetwarzania danych, uzyskuje wynik -> i zwraca wynik z powrotem do klienta jako stronę HTML (widok) ”.

OK, to trochę plątanina

MVC, cokolwiek to jest, to zbiór pomysłów na implementację interfejsów użytkownika.

REST to zbiór ograniczeń architektonicznych do tworzenia aplikacji na dużą skalę.

Internet, o którym tu mówisz, to gigantyczna aplikacja do zarządzania dokumentami zbudowana przy użyciu większości tych samych ograniczeń.

Podobieństwa, które widzisz między nimi, są (wybierz) niepoprawnie przypisane lub powierzchowne.

RESTafarianie mają wspólne rozumienie HATEOAS , „hipertekstu jako silnika stanu aplikacji”, i to powinno wysyłać alarmy dzwoniące przez twoją głowę - dlaczego widok miałby być silnikiem stanu ? Jeśli kwestionujemy tę przesłankę i szukamy dodatkowych dowodów, możemy również zauważyć dwie dziwne rzeczy.

Po pierwsze, że możemy całkowicie usunąć serwer HTTP z równania, ładując HTML z dysku. Przeglądarka jest z tego całkowicie zadowolona, ​​usprawiedliwiając niewielkie zmiany w zachowaniu, które mogą wynikać ze zmiany podstawowego adresu URL. Widoki zwykle nie działają, gdy zostały całkowicie odłączone od modelu i kontrolera w ten sposób.

Po drugie, jeśli uważnie obserwujemy nowoczesną przeglądarkę, zauważymy, że istnieje wiele widoków HTML. Wiele widoków widoku wydaje się naprawdę dziwnym pomysłem, ale na pewno jest główna prezentacja z dużą ilością znaczników tekstowych, które reagują na gesty użytkownika, a następnie jest to „Widok źródłowy”, który pokazuje surowy HTML, a także reaguje na gesty użytkownika. Żółwie do samego końca!

Odpowiedzią na zagadkę jest oczywiście to, że HTML nie jest widokiem. Zbiór widżetów w przeglądarce to widok, który komunikuje się z Document Object Model , który został zainicjowany przez odczyt HTML.

Innymi słowy, HTML jest reprezentacją stanu, tak jak obiecał Roy T. Fielding .

Co jeśli mówimy o czystej usłudze sieciowej RESTful API ...? Tak jak poprzednio, ale nie ma „widoku”

Bardziej poprawnie, tak jak poprzednio: nie ma widoku. JSON, podobnie jak HTML, jest reprezentacją stanu, odpowiednią do przekraczania granic procesu.

Pomyśl „DTO” lub „Wiadomość”, a twoje wnioski będą o wiele mniej prawdopodobne, by cię sprowadzić na manowce.

VoiceOfUnreason
źródło
Połączyłem żądania internetowe ze wzorem architektonicznym, aby łatwiej zilustrować to, co przeszkadza mi w koncepcji jako całości. Mówisz: „Zbiór widżetów w przeglądarce to widok” - następnie przeformułowuję: co, jeśli w ludzkiej scenie nie ma „przeglądarki”? Co jeśli inny robot łączy się z usługą? Jeśli JSON i HTML są reprezentacją stanu, wówczas „wiadomość” lub „DTO” jest transportem reprezentacji stanu. Gdzie zatem pojawia się „widok”? Jeszcze bardziej pomyliłeś mnie swoją odpowiedzią.
simon
Program / robot łączący się z usługą prawdopodobnie manipulowałby modelem bezpośrednio - dlaczego miałby potrzebować widoku?
VoiceOfUnreason
1

Czy tak należy to zrobić?

Przekazywanie JSON jako widoku lub używanie go jako modelu widoku do konstruowania widoku nie narusza wzorca.

Korzystam z tej samej architektury w bieżącej aplikacji, nad którą pracuję i działa bardzo dobrze. Razem z ładnym frameworkiem JS możesz tworzyć naprawdę responsywne projekty.

A może istnieją inne, lepiej dopasowane wzorce dla usługi tylko API zamiast MVC?

Szczerze mówiąc, nie mam pojęcia. Ale myślę, że to, czy używasz MVC, czy nie w API, nie jest tak ważne. Używaj wszystkiego, co uznasz za wygodne. Mówiąc o usługach internetowych, należy wziąć pod uwagę o wiele ważniejsze aspekty (niezwiązane bezpośrednio z MVC), np. Bezpieczeństwo, spójność, dostępność itp.

djvuk
źródło