Opiniones - ajax en routes o en models (Backbone.js)

[vicenreler]

Hola.
Estoy desarrollando una aplicación web haciendo uso del framework Backbone para Javascript y me gustaría saber qué opiniones hay acerca de donde es más correcto hacer la comunicación AJAX según el patrón de diseño MVC o para el caso de Backbone, MVR (Model-View-Route) para ser más concreto.
Para mi caso, tengo que hacer consultas y envío de datos en formato JSON al servidor. Opino que el código AJAX debería incluirse en el modelo porque son consultas de datos, y ya desde ahí que lo recoja la vista, pero he visto algunos ejemplos en internet donde ponen el código Ajax en cualquier parte del MVR.

¿Dónde opináis que es más correcto?

Saludos.

[maycolalvarez]

según la concepción de MVC, es el controlador el encargado de manejar la lógica de la aplicación, como manejo de protocolos, etc. el Modelo sólo se encarga de la base de datos y la lógica de negocios.

No conozco dicho FW, pero si seguimos la premisa anterior lo ideal es que lo haga el Route, porque, como el Modelo sólo se encarga de proporcionar datos, puede permanecer inalterable, depende de los cambios que ocurran en la estructura de la aplicación lo que te obligue a cambiar por ejemplo AJAX por Comet o HTML5 webSockets, en ese caso si usas el Controlador (o Route en este caso), sólo tendrás que cambiar dicha parte y dejar tu modelo inalterable

Sé que puede parecer confuso, pero los principios de MVC son claros y simples: Modelos gordos, controladores flacos.

[vicenreler]

Hola.
Según dices, y estoy de acuerdo, el modelo es el que proporciona los datos. El framework del que hablo es Javascript, por tanto funciona en el cliente. Si los datos son proporcionados por el modelo, ¿no será el que tenga que hacer las peticiones AJAX al servidor para consultar la base de datos?
Si se tratara de un MVC en PHP, el modelo consultaría la base de datos MySQL (por ejemplo), y si quisiéramos cambiar el tipo de sistema de base de datos, solamente habría que cambiar el modelo y lo demás quedaría inalterable. Claro que, si a su vez se usa otro patrón (como puede ser Abstract Factory con Factory Method) en el modelo para que haya bajo acoplamiento entre clases, sería mucho más fácil cambiar o incluir otro código que maneje otro tipo de sistema de base de datos. Pero bueno esto es otro tema. Lo que quiero decir es que quizás las competencias de un MVC en una aplicación de cliente varíen un poco a una aplicación de servidor.