Web API w rozwiązaniu MVC w osobnym projekcie

Tworzę nowy projekt MVC4, a badania doprowadziły mnie do przekonania, że ​​komunikacja z javascript do strony serwera jest teraz lepiej realizowana za pomocą struktury internetowego interfejsu API, a nie akcji kontrolera. Czy moje zrozumienie jest prawidłowe?

Zakładam, że mogę udostępniać wszystkie swoje atrybuty itp. Między kontrolerami internetowego interfejsu API i MVC, więc na pierwszy rzut oka nie wydaje mi się to ogromną zmianą.

Kiedy konfiguruję aplikacje, lubię rozdzielać komponenty na projekty. Planowałem mieć projekt MVC i projekt internetowego interfejsu API. Ale napotkałem problemy. Na przykład otrzymałem 2 aplikacje jako takie, oddzielną konfigurację routingu itp.

Więc moje pytanie brzmi, czy w aplikacji MVC struktura interfejsu API sieci Web powinna znajdować się w tym samym projekcie, czy też interfejs API sieci Web powinien być podzielony na własny projekt i obejść problemy?

Niestety mylisz się co do tego - przypuszczam, że mogę dzielić się wszystkimi swoimi atrybutami itp. Między kontrolerami web api i mvc, więc pozornie nie wydaje mi się to ogromną zmianą.

Wiele koncepcji używanych przez Web API i MVC, mimo że na pierwszy rzut oka są podobne, w rzeczywistości nie jest zgodnych. Na przykład atrybuty interfejsu API sieci Web są, System.Web.Http.Filters.Filtera atrybuty MVC są System.Web.Mvc.Filter- i nie są one zamienne.

To samo dotyczy wielu innych koncepcji - powiązanie modelu (zupełnie inne mechanizmy), trasy (interfejs API sieci Web używa HTTPRoutes, a nie Routes, mimo że oba działają na tej samej podstawowej tabeli RouteTable), mechanizm rozpoznawania zależności (niekompatybilny) i więcej - mimo że podobne w powierzchni, są w praktyce bardzo różne. Ponadto interfejs API sieci Web nie ma koncepcji obszarów.

Ostatecznie, jeśli wszystko, co próbujesz osiągnąć, to mieć „nowy, modny” sposób obsługi treści JSON - zastanów się dwa razy, zanim pójdziesz tą ścieżką. Z pewnością nie polecałbym refaktoryzacji żadnego istniejącego kodu, chyba że naprawdę chcesz objąć HTTP i zbudować swoją aplikację w sposób RESTful.

Wszystko naprawdę zależy od tego, co budujesz. Jeśli zaczynasz nowy projekt i wszystko, czego potrzebujesz, to udostępnić trochę JSON, aby ułatwić swoją aplikację internetową - pod warunkiem, że chcesz żyć z potencjalnie zduplikowanym kodem (takim jak rzeczy, o których wspomniałem powyżej), interfejs API sieci Web może być łatwo hostowany w ten sam projekt co ASP.NET MVC.

Oddzieliłbym interfejs API sieci Web na osobny projekt tylko wtedy, gdy zamierzasz zbudować odpowiedni interfejs API dla swojej usługi online - być może do wykorzystania przez klientów zewnętrznych lub różne urządzenia - na przykład do zasilania aplikacji mobilnych.

IMO, bezpieczeństwo i wdrożenie powinny wpłynąć na Twoją decyzję. Na przykład, jeśli Twoja aplikacja MVC używa uwierzytelniania formularzy, ale chcesz używać uwierzytelniania podstawowego (z SSL) dla swojego interfejsu API, oddzielne projekty ułatwią Ci życie. Jeśli chcesz hostować swoją witrynę pod adresem www.example.com, ale udostępniać swoje API jako api.example.com (zamiast www.example.com/api), osobne projekty ułatwią Ci życie. Jeśli oddzielisz swoje projekty i odpowiednio je subdomeną, a zamierzasz wykorzystać własny interfejs API z aplikacji MVC, będziesz musiał dowiedzieć się, jak poradzić sobie z problemem Same Origin Policy w przypadku wywołań po stronie klienta do interfejsu API. Typowe rozwiązania tego problemu to wykorzystanie jsonp lub CORS (najlepiej, jeśli możesz).

Aktualizacja (26.03.2013): Nadchodzi oficjalna obsługa CORS: http://aspnetwebstack.codeplex.com/wikipage?title=CORS%20support%20for%20ASP.NET%20Web%20API

Po pewnym stopniu doświadczenia (tworzenie API dla aplikacji i dla MVC). Przeważnie robię jedno i drugie.

Tworzę osobny projekt dla wywołań API pochodzących od innych klientów lub innych urządzeń (aplikacje Android / IOS). Jednym z powodów jest to, że uwierzytelnianie jest inne, jest oparte na tokenach (aby było bezstanowe). Nie chcę mieszać tego w mojej aplikacji MVC.

W przypadku wywołań api javascript / jquery do mojej aplikacji MVC, lubię upraszczać wszystko, więc dołączam interfejs API sieci Web do mojej aplikacji MVC. Nie zamierzam używać uwierzytelniania opartego na tokenach z moimi wywołaniami javascript api, ponieważ hej, jest w tej samej aplikacji. Mogę po prostu użyć [authorize]atrybutu na punkcie końcowym API, gdy użytkownik nie jest zalogowany, nie otrzyma danych.

Ponadto, gdy masz do czynienia z koszykami i chcesz przechowywać koszyk użytkownika w sesji (nie będąc zalogowanym), musisz mieć to również w swoim API, jeśli dodajesz / usuwasz produkty za pomocą kodu javascript. To z pewnością sprawi, że twój API będzie stanowy, ale także zmniejszy złożoność twojego MVC-API.

Steven z SimpleInjector (IoC Framework) doradza dwóm oddzielnym projektom: Jaka jest różnica między DependencyResolver.SetResolver i HttpConfiguration.DependencyResolver w WebAPI

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

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

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

W AssemblyInfo.cs projektu MVC 4 dodaj podobny wiersz kodu

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

Teraz potrzebujesz klasy LibraryRegistrator (możesz ją dowolnie nazwać)

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

W projekcie MVC 4 dodaj również odniesienie do biblioteki API.

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

Nawet jeśli Twój projekt jest tak złożony, że wymaga dwóch „front-endów”, nadal rozważałbym podzielenie webapi na osobny projekt jako ostateczność. Będziesz miał bóle głowy podczas wdrażania, a nowicjuszowi trudno byłoby zrozumieć strukturę Twojego rozwiązania. Nie wspominając o problemach z routingiem.

Chciałbym, aby przestrzeń nazw system.web była odizolowana w jednej „warstwie prezentacji”. Mimo że webapi nie jest prezentacyjne , nadal jest częścią interfejsu Twojej aplikacji. Dopóki utrzymujesz logikę w swojej domenie, a nie na kontrolerach, nie powinieneś napotykać zbyt wielu problemów. Nie zapomnij też skorzystać z obszarów.

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

Tylko sugestia:

1. Utwórz projekt
2. Nugget WebActivatorEx

3. Utwórz metodę klasy, która będzie wywoływana przy app_start

   [zestaw: WebActivatorEx.PostApplicationStartMethod (typeof (API.AppWebActivator), "Start")]

   [zestaw: WebActivatorEx.ApplicationShutdownMethod (typeof (API.AppWebActivator), "Shutdown")]

4. Zarejestruj trasy web.api w metodzie startowej

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

5. Odwołaj projekt do projektu sieci Web. aby aktywować metodę uruchamiania.

Mam nadzieję że to pomoże.

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

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