json - net - web api result
Usando WebAPI o MVC para devolver JSON en ASP.NET (6)
Estoy construyendo una aplicación ASP.NET MVC que es cliente-script pesado, usará JSON y jQuery para manipular el DOM.
Mi comprensión es tanto el Controlador Web API como MVC Controller puede devolver JSON.
Dado mi escenario, ¿debería usar un Controlador Web API o un Controlador MVC ?
En este escenario, recomendaría WebApi ya que es perfecto para transferir datos como este en función de las solicitudes de Javascript. Por lo general, desarrollaré mis controladores WebApi para que devuelvan un objeto compatible con JSON que mi código JavaScript pueda analizar fácilmente.
El único momento real en el que desearía usar una acción en un controlador MVC para este tipo de cosas sería si desea generar algo de HTML y reemplazar segmentos de su página con llamadas de Javascript.
Por ejemplo:
Tienes un JQuery UI Datepicker que al momento de la selección genera una lista de botones de opción que representan eventos en el día elegido.
En este escenario, podría usar WebApi para devolver algo de JSON y luego generar el HTML necesario utilizando Javascript, pero en general es una mala práctica crear mucho HTML utilizando Javascript. Sería mucho mejor tener C # construir el HTML y luego devolverlo a través de una vista parcial ya que de esta manera es menos probable que encuentre errores con el análisis de Javascript. Sin mencionar que hace que el HTML sea mucho más fácil de escribir.
Estoy de acuerdo con la respuesta de Shaun Wilson (respuesta principal), pero no estoy seguro de por qué, ya que estoy un poco confundido y todavía estoy tratando de entender con la siguiente (probablemente incorrecta) premonición:
- Use el Controlador WebAPI para entregar datos JSON al cliente para que el cliente pueda manejar la manipulación de la vista. Este proceso NO requiere una vista, sino simplemente una respuesta a lo que se llame el método (es decir, una solicitud de JavaScript) para que el cliente pueda manejar cualquier manipulación del lado del cliente.
- Utilice el controlador MVC cuando necesite usar los datos para manipular una vista durante o justo después de page_load (es decir, no para aplicaciones de SPA).
Verá, simplemente no sé cómo soy incorrecto aquí y estoy confundido porque la última línea de la respuesta de Shaun dice: "Utilizo controladores MVC para manejar el enrutamiento básico del navegador y la entrega del SPA". - Tal vez no sé exactamente qué es un cliente tranquilo cuando asumí que podría ser un método de JavaScript que recibe una respuesta en formato JSON. esta es la publicación más cercana en que se relacionó remotamente como respuesta a mi pregunta, así que estoy respondiendo esta publicación en lugar de posiblemente duplicar preguntas.
La única preocupación que tengo con ApiController es que se basa en el sitio, no en el área. Un sitio solo puede tener una subcarpeta de controlador para que pueda nombrar los métodos de su controlador. Hay situaciones en las que quizás desee duplicar el nombre del controlador en diferentes áreas:
domain.com/api/area1/controller1/
domain.com/api/area2/controller1/
Recuerdo que hay algunas configuraciones de código personalizado para poder hacer esto, pero no funciona de manera predeterminada.
La respuesta se reduce a la separación de las preocupaciones, asegurar la creación de servicios y confiar en la convención en lugar de la configuración.
La principal responsabilidad de los controladores es trabajar como coordinador entre la vista y su modelo, pero en tanto que la principal responsabilidad de la API es trabajar en los datos. En el caso de las convenciones de API, es realmente fácil realizar operaciones CRUD. A continuación se muestra el mapeo entre la operación CRUD y las acciones HTTP
- OBTENER: Leer
- POST: Crear
- PUT: Actualización
- ELIMINAR: Eliminar
Por lo tanto, con las API no tiene que crear acciones separadas y atribuirlas con acciones HTTP.
Los Controladores Web API se pueden crear y hospedar en cualquier Aplicación ASP.NET, no solo en las aplicaciones MVC. Por lo tanto, una razón obvia para crear una API web es si no tiene un front-end MVC (por ejemplo, servicios web RESTful clásicos alojados por su empresa u organización).
Los Controladores MVC suelen confiar en MVC Framework, si observa las plantillas predeterminadas y la mayoría del trabajo realizado por la comunidad y sus colegas, notará que casi todos los Controladores MVC se implementan teniendo en cuenta la Visión.
Personalmente, utilizo Controladores MVC cuando intento responder con una Vista (), y usaré una API web para cualquier cosa que no dependa de una vista en particular.
Hay advertencias, por supuesto, pero en general, si no requiere el comportamiento de enlace de modelo de MVC, su servicio está centrado en los datos y las operaciones están centradas en los datos (por ejemplo, operaciones CRUD), entonces es probable que desee un controlador web API ''en lugar de un'' Modelo-Controlador de Vista ''. Por el contrario, si sus operaciones están centradas en la visualización (por ejemplo, entregando una página de administración de usuario al usuario), o necesita el Enlace de modelo MVC para generar ''parciales ajax'' (muy poco probable), entonces querrá un Controlador MVC.
Personalmente, utilizo los controladores Web API para manejar clientes RESTful basados en JSON, utilizo controladores MVC para manejar el enrutamiento básico del navegador y la entrega del SPA.
WebAPI es para hacer una API. Si desea que alguien pueda consumir su API en XML, JSON, etc. Puede crear una API web.
En su caso, solo necesita hablar con el cliente en JSON.
A pesar de que su sitio web se basa principalmente en secuencias de comandos del cliente, todavía estaría utilizando Controlador ASP.NET MVC ¿verdad? Y dado que es posible que ya haya dividido lógicamente sus controladores en función de las entidades, entonces tiene sentido agregar esos métodos de publicación json en lugar de crear otra clase específicamente para la API web.
Entonces, para su situación particular (si lo entiendo correctamente), me quedaría con Controladores.