Ik ben een nieuw MVC4-project aan het maken en onderzoek heeft me doen geloven dat communicatie van javascript naar de server nu beter kan worden bereikt via een web-API-framework in plaats van controlleracties. Klopt dit wat ik begrijp?
Ik neem aan dat ik al mijn attributen enz. kan delen tussen web-API en MVC-controllers, dus op het eerste gezicht lijkt het voor mij geen enorme verandering.
Als ik applicaties aan het opzetten ben, deel ik graag componenten op in projecten. Mijn plan was om een MVC-project en een web-API-project te hebben. Maar ik ben tegen problemen aangelopen. Ik ben bijvoorbeeld beland met 2 apps als zodanig, aparte routering instellen etc etc.
Dus mijn vraag is, moet in een MVC-toepassing het web-API-framework binnen hetzelfde project vallen, of moet de web-API worden opgesplitst in een eigen project en de problemen omzeilen?
Antwoord 1, autoriteit 100%
Helaas heb je het mis – Ik neem aan dat ik al mijn attributen enz. kan delen tussen web-api- en mvc-controllers, dus op het eerste gezicht lijkt het voor mij geen enorme verandering.
Veel van de concepten die worden gebruikt door Web API en MVC, hoewel ze op het eerste gezicht vergelijkbaar zijn, zijn eigenlijk niet compatibel. Web API-kenmerken zijn bijvoorbeeld System.Web.Http.Filters.Filteren MVC-kenmerken zijn System.Web.Mvc.Filter– en ze zijn niet uitwisselbaar.
Hetzelfde geldt voor veel andere concepten: modelbinding (volledig verschillende mechanismen), routes (Web-API gebruikt HTTPRoutes en niet Routes, ook al werken ze allebei op dezelfde onderliggende RouteTable), afhankelijkheidsresolver (niet compatibel) en meer – ook al aan de oppervlakte gelijk, zijn in de praktijk heel verschillend. Bovendien heeft Web API geen concept van gebieden.
Als u uiteindelijk alleen maar een “nieuwe, trendy” manier wilt om JSON-inhoud te presenteren, denk dan twee keer na voordat u dat pad inslaat. Ik zou zeker niet aanraden om bestaande code te refactoren, tenzij je echt HTTP wilt omarmen en je app op een REST-manier wilt bouwen.
Het hangt allemaal echt af van wat je aan het bouwen bent. Als u een nieuw project start en u alleen wat JSON hoeft op te geven om uw web-app te vergemakkelijken – op voorwaarde dat u bereid bent te leven met een mogelijk dubbele code (zoals de dingen die ik hierboven noemde), kan Web API gemakkelijk worden gehost binnen hetzelfde project als ASP.NET MVC.
Ik zou Web API alleen in een apart project opsplitsen als je een goede API voor je online service gaat bouwen – misschien om te worden gebruikt door externe klanten of door verschillende apparaten – zoals het voeden van je mobiele apps.
Antwoord 2, autoriteit 24%
IMO, beveiliging en implementatie zouden uw beslissing moeten bepalen. Als uw MVC-app bijvoorbeeld Forms-verificatie gebruikt, maar u bent geïnteresseerd in het gebruik van basisverificatie (met SSL) voor uw API, dan zullen afzonderlijke projecten uw leven gemakkelijker maken. Als u uw site wilt hosten op www.example.com maar uw API host als api.example.com (vs. www.example.com/api), zullen afzonderlijke projecten uw leven gemakkelijker maken. Als u uw projecten scheidt en ze dienovereenkomstig subdomeinen en u van plan bent uw eigen API van uw MVC-app te gebruiken, moet u uitzoeken hoe u omgaat met de Zelfde oorsprongsbeleidprobleem voor client-side aanroepen naar uw API. Veelvoorkomende oplossingen hiervoor zijn om gebruik te maken van jsonpof CORS(bij voorkeur als je kunt).
Update (26-03-2013): Officiële CORS-ondersteuning komt eraan: http://aspnetwebstack.codeplex.com/wikipage?title=CORS%20support%20for%20ASP.NET%20Web%20API
Antwoord 3, autoriteit 8%
Na enige ervaring (maken van API voor apps en voor mvc). Ik doe meestal beide.
Ik maak een apart project voor API-oproepen die afkomstig zijn van andere klanten of andere apparaten (Android / iOS-apps). Een van de redenen is omdat de authenticatie anders is, het is gebaseerd (om het staatloos te houden). Ik wil dit niet mengen in mijn MVC-applicatie.
Voor mijn JavaScript / jQuery API roept u naar mijn MVC-applicatie, ik hou ervan dingen eenvoudig te houden, dus ik neem een web-API in mijn MVC-applicatie. Ik ben niet van plan om token-gebaseerde authenticatie te hebben met mijn JavaScript API-oproepen, omdat hij in dezelfde toepassing is. Ik kan gewoon [authorize]Attribuut gebruiken op een API-eindpunt, wanneer een gebruiker niet is ingelogd, krijgt hij de gegevens niet.
Bovendien, bij het omgaan met winkelwagentjes en wilt u een gebruikerswinkelwagen opslaan in een sessie (terwijl u niet bent ingelogd), moet u dit ook in uw API hebben als u producten toevoegt / verwijderen via uw JavaScript-code. Dit maakt uw API zeker vast, maar zal ook de complexiteit in uw MVC-API verminderen.
Antwoord 4, Autoriteit 5%
Steven uit Simpleinjector (IOC Framework) adviseert twee afzonderlijke projecten: Wat is het verschil tussen afhankelijkheidResolver.SetResolver en httpconfiguratie.DependentieResolver in webapi
Antwoord 5, Autoriteit 5%
Ik heb onlangs bijna hetzelfde gedaan: ik begon met een nieuw MVC 4 Web Application Project dat de Web API-sjabloon in VS2012 kiest.
Hiermee wordt een web-API gemaakt in dezelfde toepassing als MVC.
Ik wilde de apicontrollers verplaatsen naar een apart class-bibliotheekproject. Dit was vrij eenvoudig, maar de oplossing was een beetje verborgen.
in Assemblyinfo.cs van het MVC 4-project Voeg dezelfde code toe
[assembly: PreApplicationStartMethod(typeof(LibraryRegistrator), "Register")]
Nu heb je de Class LibraryRegistrator nodig (voel je vrij om het te noemen)
public class LibraryRegistrator
{
public static void Register()
{
BuildManager.AddReferencedAssembly(Assembly.LoadFrom(HostingEnvironment.MapPath("~/bin/yourown.dll")));
}
}
In het MVC 4-project voegt u ook een verwijzing naar de API-bibliotheek.
Nu kunt u API-controllers toevoegen aan uw eigen afzonderlijke Class Library (Yourown.dll).
Antwoord 6, Autoriteit 2%
Zelfs als uw project zo complex is om twee “front-uiteinden” te garanderen, zou ik nog steeds alleen de Webapi in een afzonderlijk project als laatste redmiddel overwegen. Je hebt inzethoofdpijn en het zou moeilijk zijn voor een newbie om de structuur van je oplossing te begrijpen. Om niet te vergeten routeringproblemen.
Ik zou willen behouden om het systeem te houden.Web NameSpace geïsoleerd in de een “presentatielaag”. Ondanks de WebAppi die niet presenteert is het nog steeds deel uit van de interface van uw toepassing. Zolang u de logica in uw domein bewaart en niet uw controllers moet u niet te veel problemen tegenkomen. Vergeet ook niet om gebieden te gebruiken.
Antwoord 7
Naast het instellen van de afzonderlijke DLL voor het web.API.
Gewoon een suggestie:
- Maak het project
- nugget webactivatorex
-
Maak een A A Class-methode om op te richten op APP_START
[ASSEMBLAGE: WebActivatorEx.PostapplicationStartMethod (TypeOf (API.AppWebActivator), “Start”)]
[ASSEMBLAGE: WebActivatorEx.ApplicationShutdownMethod (Type (API.AppWebActivator), “Shutdown”)]
-
Registreer een web.API-routes in de startmethode
Openbare statische void start () {
Globalconfiguration.configure (webapiconfig.register);
} -
Referentie het project naar het webproject. om de startmethode te activeren.
Ik hoop dat dit helpt.
Antwoord 8
Ik heb geprobeerd de API-controllers in een nieuw project te splitsen. Alles wat ik heb gedaan, is om een nieuw bibliotheekproject te maken, de controllers in de map genaamd API verplaatst.
Vervolgens de referentie van het bibliotheekproject aan het MVC-project toegevoegd.
De webAPI-configuratie blijft in het MVC-project zelf. Het werkt prima.