Patrón de controlador ASP MVC Ajax?

Question

Mi aplicación MVC tiende a tener muchas llamadas ajax (a través de JQuery.get()). Me fastidia que mi controlador esté lleno de muchos métodos pequeños que se llaman a través de ajax. Me parece que es algo así como rompiendo un poco el patrón MVC - el controlador ahora es más un componente de acceso a datos que un enrutador URI.

Refactoré para que tenga mi controlador "verdadero" para una página que solo realiza respuestas de enrutamiento estándar (objetos de ActionResponse de ajuste). Por lo tanto, una llamada a/home/obviamente activará la clase HomeController que responderá en la forma de controlador canónico devolviendo una vista normal de jane.

Luego moví mis cosas de Ajax a una nueva clase de controlador cuyo nombre me estoy imprimiendo con 'Ajax'. Entonces, por ejemplo, mi página puede tener tres secciones diferentes de funcionalidad (por ejemplo, carrito de compras o cuenta de usuario). Tengo un controlador ajax para cada uno de estos (AjaxCartController, AjaxAccountController). No hay nada realmente diferente al mover el material de llamada ajax a su propia clase de controlador; es solo para mantener las cosas más limpias. en el lado del cliente, obviamente, el jQuery entonces utilizar este nuevo controlador de esta manera:

//jquery pseudocode call to specific controller that just handles ajax calls 
$.get('AjaxAccount/Details'.... 

(1) hay una mejor patrón en MVC para responder a las llamadas ajax?

(2) Me parece que el modelo MVC tiene un poco de fugas cuando se trata de ajax - en realidad no se trata de cosas "de control". Simplemente resulta ser la mejor y la menos dolorosa forma de manejar las llamadas ajax (¿o soy un ignorante)?

En otras palabras, la abstracción 'Controlador' no parece jugar bien con Ajax (al menos desde una perspectiva de patrones). ¿Se me escapa algo?

Answer 1

Si bien es posible poner Controller en el extremo de la misma para hacer que el trabajo mágico de enrutamiento de ASP.NET MVC, que tienden a hacer lo que ya has hecho - excepto cuando leí AjaxCartController I pienso para mí mismo AjaxCartPresenter (como se en el patrón Model-View-Presenter comúnmente visto en WinForms). Es decir, este "controlador" no controla, sino que está ataviado sin vergüenza a la interfaz de visualización. Pero, a diferencia de la vista, el presentador del controlador es verificable.

Cuando AJAXificamos una página web, la convertimos en algo que puede reaccionar de manera precisa, por lo que los métodos detallados están bien. Fined-grainedness es el punto y toda la razón por la que fue inventado. Estamos alejándonos deliberadamente de REST para un escenario particular porque ese patrón particular no resuelve el requisito de UI en cuestión, sino que elige un modelo similar a RPC. Son solo patrones, uno no va a ser mejor que el otro en todas las situaciones, incluso si nuestra pila de tecnología pudiera estar empujándonos hacia uno sobre el otro. (De hecho, HTTP en sí mismo funciona mejor en trozos/páginas/entidades/documentos de transferencia de estado representativo.)

Mentalmente, puede tratar estas páginas como si fueran formularios en una aplicación WinForms; el hecho de que estos métodos se sientan en un "controlador" es solo un artefacto y una concesión hacia la tecnología que se utiliza.(Si le molesta, puede enrollar los métodos AJAX en un IHttpHandler y evitar MVC por completo, pero ¿por qué deshacerse de la búsqueda automática de enrutamiento/instanciación/método y hacerlo difícil para usted? Sería arquitectónicamente "limpio" y puro, pero de dudoso beneficio.)

... al menos, eso es lo racionalizo a me =)

Answer 2

Si tiene demasiadas solicitudes detalladas, es posible que desee tener un método de acción del controlador para atender todas las llamadas. Puede usar un 'interruptor' en el método para determinar el tipo de llamada y realizar el servicio en consecuencia en lugar de tener un trillón de métodos pequeños. Incluso puede usar constantes de cadena explícitas en lugar de números para la variable de cambio.