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

25

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?

Ema.jar
fuente
2
Creo que las personas podrían proporcionar mejores respuestas si enumerara algunas de las bibliotecas y marcos que está utilizando para admitir su aplicación MVC. Si bien el patrón MVC es independiente de la tecnología, no todos los marcos lo siguen explícitamente. Además, la mayoría de los frameworks maduros ya tienen documentación sobresaliente y saber cuál está utilizando le facilitaría dirigirlo a una explicación preexistente que siga su línea de pensamiento.
CLW
2
¿Base de datos? ¿Fuente de datos? Son solo datos.
2
Hay tantas opiniones sobre lo que se supone que es "MVC", que esta pregunta es demasiado abstracta para responder.
RemcoGerlich
2
Además, considere llamar a la API desde su código Javascript frontend, y no hacer que toque su material "MVC" de fondo.
RemcoGerlich
@Remcogerlich es por eso que propuse una adición de la implementación real que está viendo. Podría estar lidiando con un backend y una implementación frontend de mvc. También podríamos tener otro patrón que explique mejor estas diferencias.
CLW

Respuestas:

37

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.

Residuo
fuente
8
El modelo no debe tener ninguna lógica y, por lo tanto, no debe interactuar directamente con nada. El patrón MVC claramente exige que toda la lógica se coloque en los controladores. Estos controladores deben ponerse en contacto con la base de datos, API, etc. y actualizar el modelo según sea necesario. Esto mantiene la tecnología de su modelo agnóstica y garantiza que no sirva más que como un mecanismo de almacenamiento que se puede pasar a varias vistas para presentaciones y controladores para una manipulación adicional.
CLW
3
@CLW: Modelo! = Modelo de datos. Se pueden encontrar más detalles en otro lugar, por ejemplo stackoverflow.com/a/14045514/124983
Residuo
2
@CLW: la lógica de negocios no debe estar en M, V o C. Los modelos son una abstracción de un almacén de datos, las vistas y los controladores son su interfaz de usuario. Son la periferia de la aplicación real que está creando, que debería ser "solo código", que no tiene que saber cosas como bases de datos y la web.
RemcoGerlich
2
La parte "modelo" se interpreta de muchas maneras diferentes. Siempre me enseñaron que un modelo es una representación. Un modelo de tren es una representación de un tren real, con pequeñas partes móviles que se mueven igual que el real. Del mismo modo, el modelo en su aplicación es una representación de los sistemas y procesos que está construyendo para reemplazar su software. Como tal, los modelos tienen comportamiento . Ese comportamiento incorpora su "lógica de negocios". Por lo tanto, cuando ignora el acceso puro a datos CRUD, la interfaz de usuario y la interoperabilidad, lo que queda es probablemente su "modelo" - clases de dominio, reglas de negocios, etc.
anaximander
1
@RemcoGerlich No dije nada sobre lógica de negocios. Simplemente dije que, dado que la mayoría de las interpretaciones de MVC exigen que el modelo no sea más que una estructura simple que representa el estado de su aplicación, la responsabilidad de contactar a la base de datos, API, etc. no debe colocarse dentro del modelo porque debe ser libre de lógica El deber de comunicarse con la base de datos debe recaer en el controlador u otro objeto administrado por el controlador.
CLW
12

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.

Javier
fuente
1
De acuerdo: siempre se suponía que los modelos eran todo el dominio del problema. En aplicaciones complicadas siempre se suponía que era la mayor parte del código. Consistían en todo el código que no cambiaría si cambia la interfaz de usuario (por ejemplo, del sitio web a la GUI o incluso a la aplicación de línea de comandos). Piensa en un compilador. Solo una porción muy pequeña del código cambiaría si pasaras de una interfaz de usuario de línea de comando a una interfaz de usuario, o incluso una interfaz de usuario web. Todas las entrañas de tal aplicación son los modelos.
Kevin Cathcart
1
En el uso original del término Smalltalk, cada control de interfaz de usuario en la interfaz tenía su propio modelo, vista y controlador.
RemcoGerlich
5

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.

James_pic
fuente
2

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.

nulo
fuente
2

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.

CLW
fuente
44
Creo que cuando dices "modelo" aquí, te estás refiriendo al "modelo de vista", que en mi opinión es algo diferente. Un modelo de vista obtiene datos del controlador a la vista y, como tal, es un detalle de implementación de la Vista o un aspecto de las comunicaciones entre la Vista y el Controlador que realmente no encaja (depende de cómo lo vea). El "Modelo" en MVC se refiere a un modelo de sistema, una representación del sistema que incorpora sus datos, estructura y comportamiento. El modelo es estado y lógica; El controlador es lo que hace que la lógica se ejecute y el estado cambie cuando se manipula la vista.
anaximander
@anaximander No, me refiero al Modelo en una interpretación bastante estricta de MVC (ver Wikipedia, Microsoft MVC, Head First Design patterns, etc.) En esos casos, el Modelo no es más que una simple estructura para pasar datos alrededor y no hay tal cosa como un modelo de vista. Si bien la implementación de Microsoft MVC agrega varios atributos al modelo, esto es más conveniente que cualquier otra cosa. Al final, el propósito del patrón MVC era facilitar las buenas prácticas de separación de código y limitar los efectos secundarios.
CLW
1

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.

dhaupin
fuente