Web-API in MVC-Lösung in separatem Projekt

Ich erstelle ein neues MVC4-Projekt, und die Forschung hat mich zu der Überzeugung geführt, dass die Kommunikation von Javascript zur Serverseite jetzt besser über das Web-API-Framework als über Controller-Aktionen erreicht werden kann. Ist mein Verständnis in dieser Hinsicht richtig?

Ich gehe davon aus, dass ich alle meine Attribute usw. zwischen Web-API und MVC-Controllern teilen kann. Auf den ersten Blick scheint dies für mich keine massive Änderung zu sein.

Wenn ich Anwendungen einrichte, teile ich Komponenten gerne in Projekte auf. Mein Plan war ein MVC-Projekt und ein Web-API-Projekt. Aber ich bin auf Probleme gestoßen. Zum Beispiel habe ich 2 Apps als solche, separate Routing-Einrichtung usw. usw. erhalten.

Meine Frage ist also, ob in einer MVC-Anwendung das Web-API-Framework im selben Projekt enthalten sein sollte oder ob die Web-API in ein eigenes Projekt unterteilt werden sollte, um die Probleme zu umgehen.

Leider irren Sie sich darin - ich gehe davon aus, dass ich alle meine Attribute usw. zwischen Web-API und MVC-Controllern teilen kann. Auf den ersten Blick scheint es für mich keine massive Änderung zu sein.

Viele der von Web API und MVC verwendeten Konzepte sind zwar auf den ersten Blick ähnlich, aber tatsächlich nicht kompatibel. Beispielsweise sind Web-API-Attribute System.Web.Http.Filters.Filterund MVC-Attribute System.Web.Mvc.Filter- und sie sind nicht austauschbar.

Gleiches gilt für viele andere Konzepte - Modellbindung (völlig unterschiedliche Mechanismen), Routen (Web-API verwendet HTTPRoutes, keine Routen, obwohl beide auf derselben zugrunde liegenden RouteTable arbeiten), Abhängigkeitsauflöser (nicht kompatibel) und mehr - obwohl ähnlich auf der Oberfläche, sind in der Praxis sehr unterschiedlich. Darüber hinaus verfügt die Web-API nicht über ein Konzept von Bereichen.

Wenn Sie letztendlich nur eine "neue, trendige" Art der Bereitstellung von JSON-Inhalten erreichen möchten, überlegen Sie zweimal, bevor Sie diesen Weg beschreiten. Ich würde auf keinen Fall empfehlen, vorhandenen Code umzugestalten, es sei denn, Sie möchten HTTP wirklich nutzen und Ihre App auf REST-artige Weise erstellen.

Es hängt wirklich davon ab, was Sie bauen. Wenn Sie ein neues Projekt starten und lediglich JSON bereitstellen müssen, um Ihre Web-App zu vereinfachen - vorausgesetzt, Sie sind bereit, mit möglicherweise doppeltem Code zu leben (wie den oben genannten), kann die Web-API problemlos darin gehostet werden das gleiche Projekt wie ASP.NET MVC.

Ich würde die Web-API nur dann in ein separates Projekt aufteilen, wenn Sie eine geeignete API für Ihren Onlinedienst erstellen - möglicherweise zur Verwendung durch externe Kunden oder durch verschiedene Geräte -, z. B. zum Betanken Ihrer mobilen Apps.

IMO, Sicherheit und Bereitstellung sollten Ihre Entscheidung bestimmen. Wenn Ihre MVC-App beispielsweise die Formularauthentifizierung verwendet, Sie jedoch die Standardauthentifizierung (mit SSL) für Ihre API verwenden möchten, erleichtern separate Projekte Ihr Leben. Wenn Sie Ihre Website unter www.example.com hosten möchten, Ihre API jedoch als api.example.com (im Vergleich zu www.example.com/api) hosten möchten, erleichtern separate Projekte Ihr Leben. Wenn Sie Ihre Projekte trennen und entsprechend unterdomainieren und beabsichtigen, Ihre eigene API aus Ihrer MVC-App zu nutzen, müssen Sie herausfinden, wie Sie mit dem Problem der gleichen Ursprungsrichtlinie für clientseitige Aufrufe Ihrer API umgehen können . Übliche Lösungen hierfür sind die Nutzung von jsonp oder CORS (vorzugsweise wenn möglich).

Update (26.03.2013): Offizielle CORS-Unterstützung kommt: http://aspnetwebstack.codeplex.com/wikipage?title=CORS%20support%20for%20ASP.NET%20Web%20API

Nach einiger Erfahrung (Erstellen von API für Apps und für MVC). Ich mache meistens beides.

Ich erstelle ein separates Projekt für API-Aufrufe, die von anderen Clients oder anderen Geräten (Android / IOS-Apps) stammen. Einer der Gründe ist, dass die Authentifizierung unterschiedlich ist und auf Token basiert (um sie zustandslos zu halten). Ich möchte dies nicht in meiner MVC-Anwendung mischen.

Für meine Javascript / JQuery-API-Aufrufe an meine MVC-Anwendung halte ich die Dinge gerne einfach, sodass ich eine Web-API in meine MVC-Anwendung einbinde. Ich beabsichtige nicht, eine tokenbasierte Authentifizierung mit meinen Javascript-API-Aufrufen durchzuführen, da sich diese in derselben Anwendung befindet. Ich kann nur ein [authorize]Attribut auf einem API-Endpunkt verwenden. Wenn ein Benutzer nicht angemeldet ist, erhält er die Daten nicht.

Wenn Sie mit Einkaufswagen arbeiten und den Warenkorb eines Benutzers in einer Sitzung speichern möchten (während Sie nicht angemeldet sind), müssen Sie dies auch in Ihrer API haben, wenn Sie Produkte über Ihren Javascript-Code hinzufügen / löschen. Dies macht Ihre API sicher zustandsbehaftet, verringert aber auch die Komplexität Ihrer MVC-API.

Steven von SimpleInjector (IoC-Framework) empfiehlt zwei separate Projekte: Was ist der Unterschied zwischen DependencyResolver.SetResolver und HttpConfiguration.DependencyResolver in WebAPI?

Ich habe kürzlich fast das Gleiche getan: Ich habe mit einem neuen MVC 4-Webanwendungsprojekt begonnen, bei dem die Web-API-Vorlage in VS2012 ausgewählt wurde.

Dadurch wird eine Web-API erstellt, die in derselben Anwendung wie MVC gehostet wird.

Ich wollte die ApiController in ein separates Klassenbibliotheksprojekt verschieben. Das war ziemlich einfach, aber die Lösung war etwas versteckt.

Fügen Sie in AssemblyInfo.cs des MVC 4-Projekts eine ähnliche Codezeile hinzu

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

Jetzt benötigen Sie die Klasse LibraryRegistrator (Sie können sie beliebig benennen).

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

Fügen Sie im MVC 4-Projekt auch einen Verweis auf die Api-Bibliothek hinzu.

Jetzt können Sie Api-Controller zu Ihrer eigenen Klassenbibliothek (yourown.dll) hinzufügen.

Selbst wenn Ihr Projekt so komplex ist, dass zwei "Frontends" erforderlich sind, würde ich Webapi nur als letzten Ausweg in ein separates Projekt aufteilen. Sie haben Kopfschmerzen bei der Bereitstellung und es ist für einen Neuling schwierig, die Struktur Ihrer Lösung zu verstehen. Ganz zu schweigen von Routing-Problemen.

Ich würde versuchen, den system.web-Namespace in der einen "Präsentationsschicht" isoliert zu halten. Trotz der WebAPI nicht in der Präsentations ist es immer noch ein Teil der Schnittstelle der Anwendung. Solange Sie die Logik in Ihrer Domäne und nicht in Ihren Controllern behalten, sollten Sie nicht auf zu viele Probleme stoßen. Vergessen Sie auch nicht, Bereiche zu nutzen.

Zusätzlich zum Einrichten der separaten DLL für das Web.Api.

Nur ein Vorschlag:

1. Erstellen Sie das Projekt
2. Nugget WebActivatorEx

3. Erstellen Sie eine Klassenmethode, die bei app_start aufgerufen werden soll

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

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

4. Registrieren Sie eine web.api-Route innerhalb der Startmethode

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

5. Verweisen Sie das Projekt auf das Webprojekt. um die Startmethode zu aktivieren.

Hoffe das hilft.

Ich habe versucht, die API-Controller in ein neues Projekt aufzuteilen. Ich habe lediglich ein neues Bibliotheksprojekt erstellt und die Controller in den Ordner API verschoben. Fügen Sie dann die Referenz des Bibliotheksprojekts zum MVC-Projekt hinzu.

Die webAPI-Konfiguration verbleibt im MVC-Projekt selbst. Es funktioniert gut.