¿Dónde debo poner una solicitud de API en MVC?

Estoy construyendo una aplicación web usando un patrón MVC. Siguiendo este tipo de arquitectura, podemos ver que todos los métodos utilizados para interactuar con la base de datos se implementan en el modelo .

Pero, ¿qué sucede si tengo que llamar a un servicio expuesto por otros en la web? Por ejemplo, me gustaría acceder a la API de Facebook para obtener todos los seguidores de mi página, entonces, ¿dónde pongo estos métodos?

Obviamente, la vista no es una buena idea porque este módulo está dedicado a la presentación, el controlador no debe usarse para recuperar datos, pero el modelo generalmente está dedicado solo a la interacción con la base de datos.

Entonces, ¿puedes darme alguna pista sobre eso? Y por favor, ¿puede decirme si estoy cometiendo algunos errores sobre la arquitectura MVC?

El modelo no se limita a la interacción con la base de datos, el modelo es responsable de obtener y manipular los datos.

Por lo tanto, para su vista y controlador, no debería haber diferencia, si los datos provienen de una base de datos o de un servicio web o incluso son totalmente aleatorios, por lo tanto, debe hacerlo en modelo.

MVC es un patrón de presentación, que solo separa las diferentes capas de representación.

No significa que ese modelo tiene que ser un desorden uniforme de código de espagueti. Su modelo en sí también puede ser en capas, pero el controlador no debe saber de dónde provienen los datos.

Un método público en su modelo puede estructurarse de esta manera (Pseudocódigo), que puede llamar su controlador:

public MyDataClass getData(int id) {
    WebServiceData wsData = WebService->getData(id);
    DatabaseData dbData = ORM->getData(id);
    return new MyDataClass(wsData, dbData);
}

WebServicey ORMpuede ser necesario que sean instancias de interfaces que pueden ser reemplazadas por simulacros mediante inyección de dependencia, pero sus controladores y vistas no tienen que cambiar para fines de prueba.

Hay un malentendido común (¿intencional?) Sobre lo que son M, V y C. No sobre los roles que toman, sino cuáles son .

En la definición original de MVC de escritorio de MVC, eran módulos . Por lo general, una aplicación tenía varios de ellos, a veces trabajando en tripletas, a veces con una variedad de vistas y modelos que algunos controladores podían mezclar y combinar.

En los marcos web, OTOH, tienden a verse como capas , donde son solo una de cada una y se ocupan principalmente de cubrir algún nivel de abstracción subyacente: "la capa modelo abstrae la base de datos", "la capa de vista implementa la presentación", "el controlador la capa procesa la entrada del usuario ".

Entonces, diría que ya tiene un modelo, dedicado a la interacción con la base de datos, y ahora solo tiene que crear otro modelo, para tratar con su API de origen. Si los hace lo más similares posible, la mayoría del controlador y el código de visualización pueden funcionar sin problemas con cualquiera de los modelos.

Parte de la dificultad con cualquier discusión sobre MVC es que diferentes grupos lo han cooptado para que signifiquen cosas diferentes. La implementación de MVC utilizada en, digamos, una aplicación Rails, sería casi irreconocible para alguien que escriba una aplicación Swing. En la medida en que MVC sigue siendo una cosa bien definida, es más un conjunto de principios rectores (separa la aplicación principal de su representación visual, proporciona mecanismos flexibles para permitir que los dos se unan), que se pueden implementar en varios formas.

De hecho, hay una tendencia a dar nombres diferentes a los diseños derivados de MVC (vea este artículo de Martin Fowler para una discusión sobre esto), o incluso a renunciar a los nombres precisos; por ejemplo, AngularJS se describe a sí mismo como un Modelo-Vista-Lo que sea marco de referencia.

Por lo tanto, es difícil responder sin saber con qué versión de "MVC" está trabajando. Sin embargo, una solicitud de API normalmente formaría parte de la aplicación principal (la parte que no debería cambiar si decide utilizar una representación visual diferente), que en muchas implementaciones estaría contenida completamente dentro del modelo.

Aquí , el modelo se describe así:

Un modelo almacena datos que se recuperan en el controlador y se muestran en la vista. Cada vez que hay un cambio en los datos, el controlador los actualiza.

Diría que el controlador incluye la lógica de llamar al servicio o llama a un Serviceobjeto separado . Si el servicio está separado, puede crear pruebas más fácilmente, por ejemplo, si no es posible una conexión a un servicio a través de una red, algunos TestServicepodrían proporcionar respuestas de forma Servicelocal.

Consulte también esta respuesta que sugiere que el Controlador llama al servicio.

Su modelo nunca debe contener ningún código real, y debe verse como un mensaje o una estructura utilizada para administrar el contenido manipulado por el controlador y mostrado por la vista.

Su controlador debe ser responsable de contactar cualquier API, base de datos, servicios, etc. solicitando un cambio y administrando las actualizaciones necesarias para el modelo.

Toda la fuerza del patrón MVC es que desacopla la lógica (el controlador) de la vista y el estado (el modelo). Al hacerlo, ahora tiene la garantía de que solo el código en el controlador puede crear efectos secundarios, ya que la vista y el modelo simplemente no pueden realizar cambios.

También permite una mejor reutilización del código, ya que un modelo se puede compartir entre varios controladores y vistas.

Podría estar muy lejos aquí, pero así es como me siento acerca de WebApps y de trabajar con API remotas [complejas] en muchos casos:

Lo convertiría en una clase (es decir, una biblioteca de métodos de mitigación de datos) en lugar de un modelo (es decir, una pila de funciones de mitigación de datos). Parece que actuaría de forma más transparente, más lógica / esquema agnóstico, y podría usarlo en cualquier lugar sin cargar-> llamando a un modelo / controlador cada vez que quiera usarlo. La lógica aún está separada, el punto de datos sigue siendo flexible, y parece más abierto a la interoperabilidad en casos extraños como apilar clientAJAX-> appJSON-> appLIB-> remoteAPI-> remoteJSON, etc. para sondear el punto final indirectamente.