Estoy creando un nuevo MVC4 proyecto, y la investigación me ha llevado a creer que la comunicación de javascript del lado del servidor es mejor conseguido ahora a través de la web de la API de marco en lugar de las acciones del controlador. Es mi entendimiento correcto sobre esto?

Estoy suponiendo que puedo compartir todos mis atributos, etc entre la API de web y controladores MVC en el rostro de ella, no parece un gran cambio para mí.

Cuando voy a instalar aplicaciones, me gusta dividir componentes en los proyectos. Mi plan era tener un proyecto de MVC y web API proyecto. Pero he corrido en problemas. Por ejemplo, se me han acabado con 2 apps como tal, independiente de enrutamiento configurado, etc, etc.

Así que mi pregunta es, en una aplicación MVC debe la web de la API de marco sentarse dentro del mismo proyecto, o en caso de que la API de web ser separados en un proyecto de su propia y evitar los problemas?

InformationsquelleAutor amateur | 2012-10-15

8 Comentarios

  1. 106

    Desafortunadamente, usted está equivocado acerca de que – estoy suponiendo que puedo compartir todos mis atributos, etc entre la api de web y controladores mvc en el rostro de ella, no parece un gran cambio para mí.

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

    Mismo se aplica a muchos otros conceptos – modelo de enlace (mecanismos completamente diferentes), rutas (API Web utiliza HTTPRoutes no Rutas, a pesar de que ambos operan en el mismo subyacente RouteTable), dependencia de la resolución (no compatible) y más – aunque similares en la superficie, son muy diferentes en la práctica. Por otra parte, la API de Web no tiene un concepto de áreas.

    Finalmente, si todo lo que usted está tratando de lograr es tener una «nueva moda» manera de servir contenido JSON – pensar dos veces antes de ir por ese camino. Ciertamente, no recomendamos la refactorización de código existente, a menos que usted realmente está buscando en abrazar HTTP y la construcción de su aplicación en un Rest.

    Todo depende realmente de lo que están construyendo. Si usted está comenzando un nuevo proyecto, y todo lo que usted necesita es servir a algunos de JSON para facilitar su aplicación web, siempre dispuestos a vivir con algunos potencialmente duplicar código (como las cosas que he mencionado anteriormente), la API de Web fácilmente podría estar alojados en el mismo proyecto como ASP.NET MVC.

    Sólo quiero separar Web API en un proyecto independiente si usted va a construir una API adecuada para su servicio en línea, tal vez para ser consumidos por los clientes externos, o por diversos dispositivos, tales como alimentar a su mobile.

    • +1 Excelente respuesta. Pensé en un principio, tanto el MVC y WebAPI puede compartir parte del código, especialmente en el caso de los filtros, el modelo de enlace etc. pero son totalmente diferentes.
    • Gracias por tan detallada respuesta. Estoy creando una nueva aplicación web utilizando mvc controladores para servir contenido a mis puntos de vista. Mi plan es usar la api de web para manejar la comunicación de mi lado del cliente js (sitio contiene algunas funciones) para el servidor a través de la web de la api. Algunos de 3rd parties son los componentes de la construcción para el sitio que se integran en el sitio web, y el uso de la api web para comunicarse con el servidor. Así que por lo que he leído, sería su sugerencia de ser para una instalación de estas han mvc y web api en el proyecto? Tal vez tiene la api de web en un «api» de la carpeta.
    • Sí, en tal escenario, simplemente inicie una nueva MVC4 proyecto en Visual Studio, y cuando se le solicita una plantilla de proyecto (segunda pantalla), simplemente seleccione la API de Web. Que se instale en la Web de la API de Nuget y en el caso que se describe debe estar perfectamente bien. Lo que se obtiene es independiente de la Web de la API de archivo de configuración enchufado en Global.asax. Además, usted puede querer separar el API de Controladores en una carpeta separada (por defecto están junto con los controladores MVC). Por último, las rutas por defecto, obviamente, son configurados por separado y no interfieren el uno con el otro
    • Me gustaría que a mi de plomo de haber leído este post antes de que él diseñó nuestro proyecto actual.
    • Gracias por las buenas explicaciones. También tengo una aplicación MVC y uso WebAPI2 para el uso de servicio de aplicaciones para Android. Por otro lado, como David Peden dice a continuación, seguridad, el mantenimiento y la implementación de es también muy importante a la hora de crear un nuevo proyecto independiente para WebAPI. En ese caso, teniendo en cuenta que ellos, ¿qué sugeriría usted? Para crear un nuevo proyecto independiente para WebAPI o utilizar el actual proyecto de MVC? Gracias de antemano.
    • Muy buena «sólo quiero separar Web API en un proyecto independiente si usted va a construir una API adecuada para su servicio en línea, tal vez para ser consumidos por los clientes externos, o por diversos dispositivos, tales como alimentar a su mobile.» golpear el clavo en la cabeza y hace que sea fácil determinar de qué manera hacerlo.

  2. 27

    De la OMI, la seguridad y el despliegue de la unidad de su decisión. E. g., si su aplicación MVC utiliza la autenticación de Formularios, pero estás interesado en utilizar la autenticación Básica (con SSL) para su API, proyectos independientes van a hacer su vida más fácil. Si desea hospedar su sitio en http://www.example.com pero el anfitrión de su API api.example.com (vs http://www.example.com/api), proyectos independientes harán su vida más fácil. Si separas tus proyectos y subdominio en consecuencia y tiene la intención de aprovechar su propia API de su aplicación MVC, usted tendrá que encontrar la manera de lidiar con el Mismo Origen De La Política De problema por el lado del cliente llama a su API. Soluciones comunes a esto hay que aprovechar jsonp o CORS (de preferencia si se puede).

    Actualización (3/26/2013): Oficial de CORS de apoyo está por venir: la http://aspnetwebstack.codeplex.com/wikipage?title=CORS%20support%20for%20ASP.NET%20Web%20API

    • Estoy tratando de conseguir mi cabeza alrededor de las cuestiones en torno a la decisión de integrar la API de Web con mi aplicación MVC o como un proyecto independiente. Yo era capaz de implementar con éxito un API Web HelloWorld aplicación a un sub-dominio en mi servidor web. A partir de este proyecto, me va a ser probablemente utilizando el Modelo de mi MVC web de la aplicación y el código de llamada en ese proyecto. Parece que no podría ser más fácil ir por este camino de un proyecto independiente, pero, ¿qué problemas crees que yo podría correr con este enfoque?
    • Personalmente, yo no usaría su modelo de vista como su DTO de su API. Yo esperaría que esa decisión podría causar algunos problemas graves de dolor por el camino, ya la vista de los modelos y de la API de firmas divergen. SoC (en.wikipedia.org/wiki/Separation_of_concerns) es muy importante.
    • Sugiere usted para crear un nuevo proyecto independiente para WebAPI. Es eso cierto? Por otro lado, voy a crear un nuevo proyecto independiente para WebAPI (actualmente tengo una Capa de interfaz de usuario (MVC) y la Capa de Datos (Biblioteca de clases) en mi aplicación. Así, también el uso de DI, pero me pregunto si puedo usar las mismas Entidades, los Repositorios, las Interfaces y clases Abstractas en la Capa de Datos para el recién creado WebAPI proyecto y la única cosa que tengo que hacer es crear WebAPI Controladores? O no me cree también que todos ellos (Entidades, los Repositorios, las Interfaces y clases Abstractas) de nuevo por el WebAPI? Cualquier ayuda por favor?
    • Es difícil dar consejos generales que es significativo, pero suena como que usted se beneficiaría de una capa de servicios de aplicación que encapsula las entidades y los repositorios que pueden ser aprovechados por tanto de la UIs (MVC y API).
  3. 9

    Después de algún grado de experiencia (la creación de la API para aplicaciones y para mvc). Por lo general hago tanto.

    Puedo crear un proyecto independiente para llamadas a la api que vienen de otros clientes o de otros dispositivos (Android/IOS apps). Una de las razones es porque la autenticación es diferente, ya que está basada en token (para que quede apátridas). No quiero mezclar esta dentro de mi aplicación MVC.

    Para mi javascript/jquery llamadas a la api para mi aplicación mvc, me gusta mantener las cosas simples así que incluye una api de web dentro de mi aplicación MVC. No pretendo han basada en token de autenticación con mi api de javascript llamadas, porque oye, es en la misma aplicación. Puedo usar [authorize] atributo en un extremo de API, cuando el usuario no está conectado, no va a obtener los datos.

    Además, cuando se trata con carritos de la compra y desea almacenar los usuarios de un carrito de compras en un período de sesiones (mientras no conectado), la necesidad de tener en su API, así que si usted agregar/eliminar productos a través de su código de javascript. Esto hará que su API de estado para la seguridad, pero también reducir la complejidad en su MVC-API.

    • Bien @Dimi, que es un inútil con la edición para obtener algunos votos… ¿Cómo puedo rechazar estas?
    • Hacer lo que quiera. Puedo editar, no por los votos, sino para el mejor look que lleva supongo. Vaya por delante.
    • No se puede rechazar la edición, pero se puede editar de nuevo y deshacer los cambios. Esto requiere de un proceso de revisión de pares menores de 2.000 rep, pero usted tiene suficiente rep hacerlo al instante. Estoy de acuerdo en que la edición no añade ningún valor y se han lanzado de nuevo para usted.
  4. 5

    Recientemente he hecho casi la misma cosa: yo empecé con un nuevo MVC 4 proyecto de aplicación web de la elección de la API Web de plantilla en VS2012.

    Esto va a crear una API Web alojado en la misma aplicación como MVC.

    Me quería mover el ApiControllers en un proyecto de biblioteca de clases. Esto fue bastante fácil, pero la solución estaba un poco escondido.

    En AssemblyInfo.cs de la MVC 4 complemento de proyecto en la misma línea de código

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

    Ahora lo que necesita la clase LibraryRegistrator (siéntase libre de nombre de lo que sea)

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

    En el MVC 4 proyecto también agregar referencia a la Api de la biblioteca.

    Ahora usted puede agregar la Api de controladores para su propia biblioteca de clases (yourown.dll).

  5. 2

    Incluso si su proyecto es tan complejo como para justificar dos «extremos» entonces yo todavía sólo considere la posibilidad de dividir webapi en un proyecto independiente como un último recurso. Usted tendrá la implementación de los dolores de cabeza y sería difícil para un novato para entender la estructura de la solución. Por no hablar de problemas de enrutamiento.

    Me gustaría unirme a mantener el sistema.en la web de espacio de nombres aislados en la «capa de presentación». A pesar de la webapi no se de presentación es parte de la interfaz de la aplicación. Como siempre que se mantenga la lógica en su dominio y no de los controladores no debe ejecutar en demasiados problemas. También, no se olvide de hacer uso de las Áreas.

    • Mi principal razón para querer separar los proyectos es que la API no es realmente la parte delantera. Es de nivel medio.
    • «Sería difícil para un novato para entender» no es una gran razón para elegir un enfoque sobre el otro. Keep it simple, cuando sea posible, seguro, pero la complejidad de las necesidades a menudo requieren soluciones complejas. En lugar de escribir tonto código para atender a los novatos, que debe haber capacitación a los novatos a entender y escribir smart código.
  6. 0

    Además de la instalación de la DLL independiente para la Web.Api.

    Sólo una Sugerencia:

    1. Crear el Proyecto
    2. Pepita WebActivatorEx
    3. Crear un Método de clase para ser llamado app_start

      [assembly: WebActivatorEx.PostApplicationStartMethod(typeof(API.AppWebActivator),»Start»)]

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

    4. Registrar una web.la api de rutas en el interior del Método de Inicio de la

      public static void Start() {
      GlobalConfiguration.Configurar(WebApiConfig.Registro);
      }

    5. De referencia del Proyecto para el Proyecto Web. para activar el Método Start.

    Espero que esto ayude.

  7. 0

    He intentado dividir la API de controladores en un nuevo proyecto. Todo lo que he hecho es crear un nuevo proyecto de biblioteca, movió a los controladores dentro de la carpeta nombre de la API.
    Luego se agregó la referencia de la biblioteca de proyecto para el proyecto de MVC.

    La webAPI configuración es la izquierda en el proyecto de MVC en sí. Funciona bien.

Dejar respuesta

Please enter your comment!
Please enter your name here