Pracuję nad projektem w MVC, który ma aplikację mobilną, więc jedno jest jasne, że musimy użyć interfejsu API sieci Web, aby można go było używać w aplikacji mobilnej.
Po utworzeniu interfejsu API, gdy zaczęliśmy opracowywać witrynę sieci Web, jesteśmy zdezorientowani i rozmawialiśmy o tym, czy użyć interfejsu API, czy bezpośrednio uzyskać dostęp do obiektu biznesowego. Skończyło się na tym, że mieliśmy bardziej doświadczonego programistę opiniotwórczego do korzystania z interfejsu API sieci Web zamiast bezpośredniego używania obiektu biznesowego.
Mam wątpliwości co do tej struktury rozwiązania.
1) Dlaczego powinniśmy korzystać z interfejsu API sieci Web i składać żądania HTTP (co jest czasochłonne), aby uzyskać lub umieścić dane zamiast obiektu biznesowego bezpośrednio w tym samym rozwiązaniu.
2) Po argumentach powiedzieli, co jeśli klient chce hostować API i Internet na innym serwerze w chmurze i stosować skalowanie tylko na API lub może chcieć mieć inny adres URL do uzyskiwania dostępu do API i Web (co jest logiczne). Czy w takim przypadku powinniśmy wywołać Web API z aplikacji MVC w tym samym rozwiązaniu?
3) Jeśli hostujemy API i Internet na innym hostingu, oznacza to, że nasza Sieć będzie używać WebClient i będzie nawiązywać połączenia HTTP na każdej nawigacji. Czy to jest poprawne?
4) Jeśli obiekt biznesowy zostanie utworzony zarówno z interfejsu API, jak i hostingu na innym serwerze, to jeśli coś zmieni się w BL, będzie trzeba zaktualizować kompilację na obu serwerach.
5) Lub powinniśmy stworzyć tylko jeden projekt dla API i możemy dodawać widoki lub strony HTML w celu opracowania interfejsu WWW, aby w ten sposób można było wywoływać API bezpośrednio z ajax.
Zgodnie z moją wiedzą # 5 jest najlepszym rozwiązaniem lub API służy tylko do dostępu stron trzecich. Jeśli mamy DB, EF, warstwę danych i warstwę biznesową w tym samym rozwiązaniu, nie powinniśmy używać interfejsu API do wykonywania połączeń HTTP i bezpośredniego dostępu do obiektu biznesowego. (popraw mnie, jeśli się mylę) API jest potrzebne, gdy aplikacja mobilna lub komputer stacjonarny lub ktoś chce uzyskać dostęp do aplikacji, abyśmy mogli mieć to samo repozytorium i warstwę danych.
W moim scenariuszu muszę utworzyć interfejs API, ponieważ mamy również aplikację mobilną, a po stronie interfejsu API projektu nazwaliśmy warstwę biznesową (oddzielny projekt), a warstwa biznesowa komunikuje się z warstwą dostępu do danych (oddzielny projekt). Więc moje pytanie brzmi: czy hostujemy nasz interfejs API i sieć na różnych serwerach, wówczas wywołanie interfejsu API będącego żądaniem HTTP może potrwać dłużej niż używanie metody z warstwy biznesowej podczas tworzenia projektu i mamy .dll warstwy biznesowej. W kontrolerze API po prostu przekształcamy put naszej firmy na format json.
Szukałem w Internecie, ale nie uzyskałem przekonującej odpowiedzi. Znalazłem blog http://odetocode.com/blogs/scott/archive/2013/07/01/on-the-coexistence-of-asp-net-mvc-and-webapi.aspx omawiający ten sam punkt, ale znowu na tym blogu mam pytanie, dlaczego musimy rozważyć scenariusz nr 3?
Aktualizacja: Możemy mieć inny projekt API i projekt MVC i możemy wywoływać API z sieci za pomocą jvascript lub możemy użyć wzorca MVVM.
źródło
Odpowiedzi:
Świetne pytanie! Zawsze szukam lepszego sposobu ustrukturyzowania moich projektów. Każdy podniesiony przez ciebie punkt ma swoje zalety i po zbadaniu różnych struktur rozwiązań muszę powiedzieć, że zgadzam się z większością komentarzy tutaj: nie ma idealnego rozwiązania. Kilka pytań, które należy sobie zadać w obliczu tego rodzaju problemu: jak złożona jest ta aplikacja? Z iloma systemami będę musiał zintegrować - lub ile systemów będzie wymagało integracji z tym systemem? Ile testów planuję zrobić? Czy istnieje osobny zespół ds. Projektowania / interfejsu użytkownika? Czy będziemy musieli skalować? Co stanowi sesję?
Spójrzmy na kilka scenariuszy i sposoby wykorzystania odrobiny sprytnej inżynierii, aby wszystko naprawdę wybuchło (i kilka sztuczek, aby uczynić to trochę łatwiejszym).
Hostowanie zarówno interfejsu API, jak i strony internetowej w tym samym projekcie
W tym przypadku możesz mieć jedno rozwiązanie z zerową lub większą liczbą projektów warstwy biznesowej i pojedynczym hybrydowym projektem MVC / WebAPI (a także innymi projektami - narzędziowymi itp.).
Pro's
Wszystko jest w jednym miejscu. Nie musisz klaksonować w skomplikowanych wiadomościach (połączenia HttpClient), możesz mieć stan wspólnej sesji (klient i serwer za pomocą plików cookie, sesja InProc / OutOfProc itp.), Pula połączeń, wspólna logika itp. Wdrożenie nie może być prostsze.
Con's
Everything jest w jednym miejscu .. To prawdopodobnie najbardziej monolityczna możliwa struktura. Nie ma jasno zdefiniowanych interfejsów między twoimi warstwami. Skończysz z wysoką spójnością . Leniwi programiści unikają interfejsów podczas pracy z tego rodzaju architekturą, co sprawia, że testowanie jest ogromnym problemem. Skalowanie / kolokacja aplikacji będzie trudne.
Używałbym
tej struktury projektu do jednorazowej, wewnętrznej lub prostej aplikacji. Budujesz szybki system śledzenia rejestracji do obozu koszykówki w lokalnym Y? To twoja architektura!
WebAPI i strona internetowa w różnych projektach
Wolę ten przypadek. Masz jedno rozwiązanie z jednym (lub więcej) projektami MVC i jednym projektem WebAPI.
Modularyzacja Pro ! Luźne powiązanie! Każdy projekt może być samodzielny, testowany osobno i może być zarządzany inaczej. Umożliwia to łatwiejsze wdrażanie różnych strategii buforowania w zależności od potrzeb. Utrzymując stałe granice między różnymi systemami, możesz łatwiej zawierać umowy, które pozwalają egzekwować określone wzorce użytkowania i ograniczać potencjalne tarcie (czytaj: mniej błędów przy mniejszej możliwości nadużywania API). Skalowanie jest nieco łatwiejsze, ponieważ wystarczy skalować tylko te bity, które widzą duże obciążenie. Integracja staje się również nieco łatwiejsza w obsłudze, ponieważ będziesz musiał mieć pojęcie o tym, jak będzie wyglądał Twój interfejs API od samego początku.
Konserwacja Con jest nieco trudniejsza. Wiele projektów oznacza, że będziesz potrzebować właścicieli projektów / funkcji, aby śledzić fuzje, kontrakty (interfejsy), wdrożenia itp. Utrzymanie kodu, dług techniczny , śledzenie błędów, zarządzanie stanem - wszystkie stają się problemami, ponieważ mogą wymagać implementacji w różny sposób na twoje potrzeby. Tego rodzaju aplikacje również wymagają największego planowania i kuracji w miarę ich wzrostu.
Używa
budowania aplikacji, która mogłaby dziś mieć 100 użytkowników i 100 000 w przyszłym tygodniu / miesiącu? Czy aplikacja musi wysyłać powiadomienia, zarządzać złożonymi przepływami pracy i mieć wiele interfejsów (web + aplikacja mobilna + SharePoint)? Masz dużo czasu i uwielbiasz rozwiązywać ponad 5000 łamigłówek w weekend? To jest architektura dla Ciebie!
Wskazówki
Po nakreśleniu powyższego rozumiem, jak twój następny projekt może wyglądać nieco zniechęcająco. Nie martw się, oto kilka sztuczek, których nauczyłem się przez lata.
źródło
Bezpośredni dostęp do obiektów biznesowych bezpośrednio (zakładam, że masz na myśli kontroler) będzie szybszy i łatwiejszy.
Następnie musisz hostować je osobno ... ale to nie brzmi dla mnie zbyt logicznie, na pewno chciałbyś skalować oba. Czy na pewno musisz spełnić ten wymóg? To brzmi jak przesada. Pamiętaj o YAGNI - jeśli go nie potrzebujesz, nie buduj go. Kiedy go potrzebujesz, zbuduj go.
Jeśli to ja zbudowałbym witrynę przy użyciu technologii, która najlepiej pasuje do witryny, to kiedy (jeśli) potrzebujesz usługi, którą inni mogą nazwać, zbuduj ją osobno.
źródło
Powiedziałbym; wolą MVC wywołujące WebAPI przez HTTPClient. Przytłaczająca jest logika „core dll”, ale główną zaletą jest to, że cały system będzie miał dostęp do obiektów domeny na HTTP za pośrednictwem jednego punktu ... W każdym razie… z odbieraniem architektury Micro Service ORAZ aplikacjami już przełączającymi się na Frameworki po stronie klienta (AngularJS itp.) .... lepiej traktuj MVC jako kolejnego klienta ... i ucz swojego zespołu, aby dobrze zarządzał interfejsami API ...
UTRZYMUJ TO SIMPE. Mam nadzieję, że to pomoże. Dzięki..
źródło