mvc - web api json c#

API web en solución MVC en proyecto separado

Question

Estoy creando un nuevo proyecto MVC4, y la investigación me ha llevado a creer que la comunicación desde JavaScript hacia el servidor se logra mejor ahora a través del marco API web en lugar de las acciones del controlador. ¿Está mi entendimiento correcto en esto?

Supongo que puedo compartir todos mis atributos, etc. entre la API web y los controladores MVC, así que, en primer lugar, no parece un cambio enorme para mí.

Cuando estoy configurando aplicaciones, me gusta dividir componentes en proyectos. Mi plan era tener un proyecto de MVC y un proyecto de API web. Pero he corrido a problemas. Por ejemplo, he terminado con 2 aplicaciones como tal, configuración de enrutamiento por separado, etc.

Entonces, mi pregunta es, ¿en una aplicación MVC debería el marco API web ubicarse dentro del mismo proyecto, o debería la API web separarse en un proyecto propio y solucionar los problemas?

Answer 1

Además de configurar el DLL por separado para Web.Api.

Sólo una sugerencia:

1. Crea el proyecto
2. Nugget WebActivatorEx

3. Crear un método de clase a invocar app_start

   [assembly: WebActivatorEx.PostApplicationStartMethod (typeof (API.AppWebActivator), "Inicio")]

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

4. Registre las rutas web.api dentro del método de inicio

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

5. Referencia el proyecto al proyecto web. para activar el Método de inicio.

Espero que esto ayude.

Answer 2

Después de cierto grado de experiencia (creando API para aplicaciones y para mvc). Principalmente hago las dos cosas.

Creé un proyecto separado para llamadas a API que provienen de otros clientes u otros dispositivos (aplicaciones Android / IOS). Una de las razones es porque la autenticación es diferente, está basada en token (para mantenerla sin estado). No quiero mezclar esto dentro de mi aplicación MVC.

Para mis llamadas javascript / jquery api a mi aplicación mvc, me gusta mantener las cosas simples, así que incluyo una API web dentro de mi aplicación MVC. No pretendo tener autenticación basada en token con mis llamadas javascript api, porque bueno, está en la misma aplicación. Solo puedo usar el atributo [authorize] en un punto final API, cuando un usuario no está conectado, no obtendrá los datos.

Además, cuando se trata de carritos de la compra y desea almacenar un carrito de compras de los usuarios en una sesión (mientras no está conectado), debe tener esto en su API también si agrega / elimina productos a través de su código de JavaScript. Esto hará que su API sea segura, pero también reducirá la complejidad en su MVC-API.

Answer 3

Incluso si su proyecto es tan complejo como para garantizar dos "interfaces", yo solo consideraría dividir a los webapi en un proyecto separado como último recurso. Tendrá dolores de cabeza en la implementación y le resultará difícil a un novato comprender la estructura de su solución. Sin mencionar los problemas de enrutamiento.

Me gustaría mantener el espacio de nombres del sistema.web aislado en la "capa de presentación". A pesar de que los webapi no son de presentación , todavía forman parte de la interfaz de su aplicación. Mientras mantenga la lógica en su dominio y no en sus controladores, no debería encontrarse con demasiados problemas. Además, no te olvides de hacer uso de las Áreas.

Answer 4

La OMI, la seguridad y la implementación deberían impulsar su decisión. Por ejemplo, si su aplicación MVC utiliza la autenticación de Formularios, pero está interesado en utilizar la autenticación básica (con SSL) para su API, proyectos separados le facilitarán la vida. Si desea alojar su sitio en www.example.com pero hospedar su API como api.example.com (frente a www.example.com/api), proyectos separados le facilitarán la vida. Si separa sus proyectos y los subdivide en consecuencia y tiene la intención de aprovechar su propia API desde su aplicación MVC, tendrá que averiguar cómo lidiar con el problema de Política de origen para las llamadas del lado del cliente a su API. Las soluciones comunes a esto son aprovechar jsonp o CORS (preferiblemente si puedes).

Actualización (26/3/2013): Se ofrecerá soporte oficial de CORS: http://aspnetwebstack.codeplex.com/wikipage?title=CORS%20support%20for%20ASP.NET%20Web%20API

Answer 5

Lamentablemente, usted está equivocado al respecto, estoy suponiendo que puedo compartir todos mis atributos, etc. entre los controladores web api y mvc, así que en primera instancia, no parece un cambio masivo para mí.

Muchos de los conceptos utilizados por Web API y MVC, aunque son similares a primera vista, en realidad no son compatibles. Por ejemplo, los atributos de la API web son System.Web.Http.Filters.Filter y los atributos de MVC son System.Web.Mvc.Filter , y no son intercambiables.

Lo mismo se aplica a muchos otros conceptos: vinculación de modelos (mecanismos completamente diferentes), rutas (Web API usa HTTPRoutes, no Rutas, aunque ambos operan en la misma tabla subyacente de RouteTable), resolvedor de dependencias (no compatible) y más, aunque similar en el superficie, son muy diferentes en la práctica. Además, la API web no tiene un concepto de áreas.

En definitiva, si todo lo que intenta hacer es tener una forma "nueva y moderna" de servir contenido JSON, piense dos veces antes de seguir ese camino. Ciertamente, no recomendaría la refacturación de ningún código existente a menos que realmente esté buscando abrazar HTTP y construir su aplicación de manera RESTful.

Todo depende de lo que estás construyendo. Si está comenzando un nuevo proyecto, y todo lo que necesita es servir algo de JSON para facilitar su aplicación web, siempre que esté dispuesto a vivir con algún código potencialmente duplicado (como las cosas que mencioné anteriormente), Web API podría alojarse fácilmente dentro de el mismo proyecto que ASP.NET MVC.

Solo separaría la API web en un proyecto separado si va a construir una API adecuada para su servicio en línea, tal vez para ser consumida por clientes externos o por varios dispositivos, como alimentar sus aplicaciones móviles.

Answer 6

Recientemente he hecho casi lo mismo: comencé con un nuevo proyecto de aplicación web MVC 4 eligiendo la plantilla de API web en VS2012.

Esto creará una API web alojada en la misma aplicación que MVC.

Quería mover los ApiControllers a un proyecto de biblioteca de clases separado. Esto fue bastante fácil, pero la solución estaba un poco oculta.

En AssemblyInfo.cs del proyecto MVC 4 agregue una línea de código similar

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

Ahora necesitas la clase LibraryRegistrator (no dudes en ponerle el nombre)

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

En el proyecto MVC 4 también se agrega una referencia a la biblioteca Api.

Ahora puede agregar controladores Api a su propia biblioteca de clases separada (yourown.dll).

Answer 7

Steven de SimpleInjector (framework de IoC) aconseja dos proyectos separados: ¿Cuál es la diferencia entre DependencyResolver.SetResolver y HttpConfiguration.DependencyResolver en WebAPI?

Answer 8

Traté de dividir los controladores API en un nuevo proyecto. Todo lo que hice fue crear un nuevo proyecto de biblioteca, moví los controladores dentro de una carpeta llamada API. Luego se agregó la referencia del proyecto de la biblioteca al proyecto MVC.

La configuración de webAPI se deja en el propio proyecto MVC. Funciona bien.