Web API w rozwiązaniu MVC w oddzielnym projekcie

Question

Tworzę nowy projekt MVC4, a badania doprowadziły mnie do przekonania, że ​​komunikowanie się z javascript po stronie serwera jest teraz lepiej osiągane dzięki strukturze API, a nie kontrolerom. Czy moje zrozumienie jest prawidłowe?

Zakładam, że mogę dzielić się wszystkimi moimi atrybutami itp. Pomiędzy interfejsem API sieci Web a kontrolerami MVC, więc na pierwszy rzut oka nie wydaje mi się to ogromną zmianą.

Kiedy konfiguruję aplikacje, lubię dzielić komponenty na projekty. Mój plan polegał na projekcie MVC i projekcie web API. Ale natknąłem się na problemy. Na przykład znalazłem 2 aplikacje jako oddzielną konfigurację routingu itp.

Moje pytanie brzmi: czy w aplikacji MVC struktura interfejsu API sieci powinna znajdować się w obrębie tego samego projektu, czy też interfejs webowy powinien być oddzielony do własnego projektu i obejść problemy?

Answer 1

Niestety mylisz się o tym - jestem zakładając, że mogę podzielić się wszystkie moje atrybuty itp pomiędzy api internetowej i MVC kontrolerów więc na oczy, to nie wydaje się ogromne zmiany dla mnie.

Wiele koncepcji używanych przez Web API i MVC, chociaż na pierwszy rzut oka są podobne, w rzeczywistości nie są kompatybilne. Na przykład atrybuty interfejsu Web API to System.Web.Http.Filters.Filter, a atrybuty MVC to System.Web.Mvc.Filter - i nie można ich stosować zamiennie.

To samo dotyczy wielu innych koncepcji - wiązania modelu (zupełnie różne mechanizmy), tras (Web API używa HTTPRoutes nie Routes, nawet jeśli oba działają na tej samej podstawowej RouteTable), resolver zależności (niekompatybilny) i więcej - nawet choć podobne na powierzchni, są bardzo różne w praktyce. Co więcej, Web API nie ma koncepcji obszarów.

Ostatecznie, jeśli wszystko, co próbujesz osiągnąć, to mieć "nowy, modny" sposób wyświetlania treści JSON - pomyśl dwa razy zanim zejdziesz tą ścieżką. Z pewnością nie polecałbym refaktoryzacji żadnego istniejącego kodu, chyba że naprawdę chcesz się zająć przygotowaniem HTTP i budowaniem aplikacji w RESTOWNOWY sposób.

To wszystko zależy od tego, co budujesz. Jeśli rozpoczynasz nowy projekt i potrzebujesz tylko trochę JSON, aby ułatwić korzystanie z aplikacji internetowej - pod warunkiem, że zechcesz żyć z potencjalnie zduplikowanym kodem (jak na przykład to, o czym wspomniałem powyżej), interfejs Web API może być łatwo hostowany wewnątrz ten sam projekt, co ASP.NET MVC.

Chciałbym oddzielić Web API tylko do oddzielnego projektu, jeśli zamierzasz zbudować odpowiedni interfejs API do swojej usługi online - być może będzie on używany przez klientów zewnętrznych lub przez różne urządzenia - na przykład do zasilania Twoich aplikacji mobilnych.

Answer 2

Nawet jeśli twój projekt jest tak złożony, że gwarantuje dwa "front endy", to nadal rozważałbym tylko podzielenie webapi na osobny projekt w ostateczności. Będziesz mieć problemy z rozmieszczeniem i początkującym trudno będzie zrozumieć strukturę twojego rozwiązania. Nie wspominając o problemach z routingiem.

Chciałbym zachować przestrzeń nazw system.web izolowaną w jednej "warstwie prezentacji". Pomimo, że webapi nie jest prezentacyjny, to nadal jest częścią interfejsu twojej aplikacji. Tak długo, jak utrzymujesz logikę w swojej domenie, a nie kontrolerów, nie powinieneś mieć zbyt wielu problemów. Ponadto nie zapomnij skorzystać z Obszarów.

Answer 3

IMO, bezpieczeństwo i wdrożenie powinny kierować twoją decyzją. Na przykład., jeśli twoja aplikacja MVC korzysta z uwierzytelniania Forms, ale chcesz używać uwierzytelniania podstawowego (z SSL) dla swojego interfejsu API, oddzielne projekty ułatwią Ci życie. Jeśli chcesz hostować witrynę na www.example.com, ale hostować swoje API jako api.example.com (w porównaniu do www.example.com/api), oddzielne projekty ułatwią Ci życie. Jeśli podzielisz swoje projekty i poddomeny odpowiednio do nich i zamierzasz wykorzystać swój własny interfejs API z aplikacji MVC, będziesz musiał dowiedzieć się, jak radzić sobie z problemem Same Origin Policy dla wywołań po stronie klienta do Twojego API. Typowymi rozwiązaniami są: jsonp lub CORS (najlepiej jeśli możesz).

Aktualizacja (26.03.2013): Oficjalne wsparcie CORS nadchodzi: http://aspnetwebstack.codeplex.com/wikipage?title=CORS%20support%20for%20ASP.NET%20Web%20API

Answer 4

Steven od SimpleInjector (MKOl ramowe) doradza dwa odrębne projekty: What is the difference between DependencyResolver.SetResolver and HttpConfiguration.DependencyResolver in WebAPI

Answer 5

Niedawno zrobił prawie to samo: Zacząłem od nowego projektu aplikacji internetowej MVC 4, wybierając szablon Web API w VS2012.

Spowoduje to utworzenie Web API hostowanego w tej samej aplikacji co MVC.

Chciałem przenieść ApiControllers do oddzielnego projektu biblioteki klas. Było to dość łatwe, ale rozwiązanie było nieco ukryte.

W AssemblyInfo.cs projektu MVC 4 dodać podobną linię kodu

[assembly: PreApplicationStartMethod(typeof(LibraryRegistrator), "Register")] 

Teraz trzeba się LibraryRegistrator klasy (nie krępuj się go niezależnie nazwa)

public class LibraryRegistrator 
    { 
     public static void Register() 
     { 
      BuildManager.AddReferencedAssembly(Assembly.LoadFrom(HostingEnvironment.MapPath("~/bin/yourown.dll"))); 
     } 
    } 

W MVC 4 projekt również dodać odniesienie do biblioteki Api.

Teraz możesz dodać kontrolery Api do swojej własnej biblioteki klas (yourown.dll).

Answer 6

Po pewnym doświadczeniu (tworzenie API dla aplikacji i dla mvc). W większości robię jedno i drugie.

Tworzę osobny projekt dla połączeń API pochodzących od innych klientów lub innych urządzeń (aplikacje Android/IOS). Jednym z powodów jest to, że uwierzytelnianie jest inne, oparte na tokenie (aby zachować status bezpaństwowca). Nie chcę tego mieszać w mojej aplikacji MVC.

W przypadku wywołań javascript/jquery api do mojej aplikacji mvc, lubię utrzymywać rzeczy proste, więc dołączam api do stron WWW w mojej aplikacji MVC. Nie mam zamiaru używać uwierzytelniania opartego na tokenach za pomocą wywołań javascript api, ponieważ hej, jest w tej samej aplikacji. Mogę po prostu użyć atrybutu [authorize] na punkcie końcowym API, gdy użytkownik nie jest zalogowany, nie dostanie danych.

Co więcej, gdy zajmujesz się koszykami i chcesz przechowywać koszyk użytkownika w sesji (bez zalogowania się), musisz mieć to również w swoim API, jeśli dodasz/usuniesz produkty za pomocą kodu javascript . To sprawi, że Twój interfejs API stanie się ważny, ale zmniejszy również złożoność interfejsu MVC-API.

Answer 7

Oprócz konfiguracji oddzielnej biblioteki DLL dla Web.Api.

tylko sugestia:

1. Tworzenie projektu
2. Nugget WebActivatorEx

3. Tworzenie aa metoda klasy zostać wezwany app_start

   [montażu: WebActivatorEx.PostApplicationStartMethod (typeof (API. AppWebActivator), "Start")]

   [montaż: WebActivatorEx.ApplicationShutdownMethod (t ypeof (API.AppWebActivator), "Shutdown")]

4. zarejestrować tras web.api wewnątrz metody start

   public static void start() { GlobalConfiguration.Configure (WebApiConfig.Register); }

5. Odwołanie projektu do projektu WWW. aktywować metodę Start.

Mam nadzieję, że to pomoże.

Answer 8

Próbowałem podzielić kontrolery API na nowy projekt. Wszystko, co zrobiłem, to stworzyć nowy projekt biblioteczny, przenieść kontrolery do folderu o nazwie API. Następnie dodano odniesienie do projektu biblioteki do projektu MVC.

Konfiguracja webAPI jest pozostawiona w samym projekcie MVC. To działa dobrze.