Discusión sobre el artículo "Plantilla para proyectar el MVC y posibilidades de uso"

Nuevo comentario
 

Artículo publicado Plantilla para proyectar el MVC y posibilidades de uso:

En el artículo, analizaremos una plantilla de MVC bastante extendida. Asimismo, estudiaremos sus posibilidades y las ventajas y desventajas de su uso en los programas MQL. Su esencia consiste en "dividir" el código existente en tres componentes separados: Modelo (Model), Vista (View) y Controlador (Controller).

En este artículo, nos interesará el "MVC clásico", sin complicaciones y con funcionalidad adicional. Su esencia consiste en "dividir" el código existente en tres componentes separados: Modelo (Model), Vista (View) y Controlador (Controller). La esencia de la plantilla MVC consiste en que estos tres componentes pueden desarrollarse y acompañarse entre sí de forma independiente. Un grupo aparte de desarrolladores puede trabajar en cada componente, para lanzar así nuevas versiones y eliminar errores. Está claro que, en este caso, se hace mucho más sencillo trabajar en un proyecto común, a la vez que podemos estudiar la información de otros de forma más rápida y más fácil.

Vamos a analizar lo que supone cada componente por separado.

  1. Vista (View). La vista es responsable de la representación visual. En un caso más general, se encarga de enviar datos al usuario. Debemos tener en cuenta que en realidad los métodos de representación de datos pueden ser varios. Por ejemplo, los datos pueden visualizarse como un recuadro, un gráfico o diagrama al mismo tiempo. En otras palabras, dentro de una sola aplicación construida según el esquema MVC, puede haber varias Vistas. Las Vistas reciben datos del Modelo sin tener idea de lo está sucediendo dentro del mismo.
  2. Modelo (Model). El modelo contiene los datos. Asimismo, establece la comunicación con las bases de datos, envía las solicitudes a la red y a otras fuentes. Además, modifica los datos, los registra, los guarda y los elimina. El modelo no sabe nada sobre el funcionamiento de la Vista ni cuántas Vistas están disponibles, pero dispone de las interfaces necesarias sobre las que las Vistas pueden solicitar datos. Las Vistas no pueden hacer nada más: no pueden obligar al Modelo a cambiar su estado. De esto se encraga el Controlador. De forma interna, el Modelo puede constar de varios otros modelos alineados en una jerarquía o funcionando por igual. En este sentido, el Modelo no impone restricciones, excepto la ya mencionada: el Modelo mantiene su dispositivo interno en secreto respecto a la Vista y el Controlador.
  3. Controlador (Controller). El Controlador hace posible la conexión entre el usuario y el Modelo. El Controlador no sabe lo que el modelo hace con los datos, pero puede decirle al Modelo que ha llegado el momento de actualizar el contenido. En general, el Controlador, según su interfaz, trabaja con el Modelo sin intentar entender lo que está sucediendo en su interior.

Visualmente, la conexión entre los componentes individuales de la plantilla de MVC se ve así:

Autor: Andrei Novichkov

 

¡material de artículo bien escrito, muy fácil de leer, gracias!

Creo que esta plantilla es ideal para un probador - es fácil cambiar la lógica EA y añadir nuevas funcionalidades a la misma

sobre MVC - ¿cómo propones para manejar los errores? por ejemplo, errores al cerrar / abrir órdenes para el comercio real.

 

La plantilla es buena porque es muy sencilla y clara. Y realmente facilita la vida, lo he experimentado de primera mano. En general, toda la herramienta se puede desglosar en ladrillos separados, y desglosados razonablemente, lógicamente. Puedes obtener reutilización de código, depuración, corrección de errores y soporte de versiones.

No pensé en la gestión de errores cuando escribía, gracias. Y en esencia, creo que deben ser manejados en el componente donde se produjeron. Es decir, si la configuración de la orden es referida a la Vista, entonces debería ser manejada allí. Pero también hay un problema si lo haces de forma asíncrona. Los manejadores de eventos en el Controlador, resulta ser un poco estrecho.

Gracias por tu amable opinión )

 
Andrei Novichkov:

Y esencialmente, creo que deberían tratarse en el componente donde se originaron.

todo el mundo lo hace, es lógico - pero el problema es qué hacer si se produce un error y se requiere la ejecución posterior del código (que está por debajo) no se ejecuta (abort/ o rollback), pensé que tal vez su artículo pondrá de relieve este punto.

 
Está describiendo una excepción )
 
Andrei Novichkov:
Estás describiendo una excepción).

¿Qué excepciones? - no existen en MQL, y tal vez uno de los desarrolladores escribió que es un mal estilo de escribir programas, no es necesario... bueno, ¡no es exacto! ))))


SZY: imho, para un tester deberias escribir en MVC, para real deberias mover una parte de codigo con secciones criticas a OnTimer() y ... y de nuevo en lugar de un simple código legible utilizando plantillas de programación comunes (métodos) obtendremos..... probablemente un programa al estilo MQL ))))

 

El ejemplo no es muy bueno, de hecho la vista está fuera del EA.

Para exagerar - usted no debe mantener la lógica del modelo en las funciones de comercio. Si un error afecta a la lógica - la función lanza un evento, el controlador lo procesa, el modelo decide qué hacer a continuación.

 
MVC no es una plantilla rígida y permite desviaciones. Hay, por supuesto, "campeones de la pureza", pero esto debe ser tratado como un fenómeno de la naturaleza
 

En principio, es terrible. Anunciaron un patrón útil, pero mostraron cómo no hacerlo: después de todo, MVC es POO, y aquí, con el pretexto de una supuesta simplificación del código, tenemos unos laberintos. Al menos podrían haber lanzado init (aka controlador) en el modelo y la vista:

int OnInit()
{
   init.Initialize(smb);
   view.Initialize(&init);
   // model.Initialize(&init);
  
   return INIT_SUCCEEDED;
}
¡¿Cómo se puede usar un objeto global dentro de la clase de otro, en el fichero de cabecera de otro?!
 
Stanislav Korotky:

En principio, es terrible. Anunciaron un patrón útil, pero mostraron cómo no hacerlo: después de todo, MVC es POO, y aquí, con el pretexto de una supuesta simplificación del código, tenemos algunos laberintos. Al menos han lanzado init (aka controlador) dentro del modelo y la vista:

¡¿Cómo puedes usar un objeto global dentro de la clase de otro, en el fichero de cabecera de otro?!

¿Has leído hasta el final? Escribí al final sobre la comunicación entre componentes. Y también sobre el acceso a objetos globales. En este caso, considero aceptable el método presentado, sólo para la comprensión de la mayoría. Y la forma que sugieres implica el mismo acceso incontrolado a los objetos globales, sólo que desde el lateral.

 

resulta ser mucho más complicado - MVC , MVP , MVVM hubr: https: //habr.com/ru/post/215605/

Si te crees el hubr, el autor tiene razón, en MVC un modelo no debe conocer (depender de) nada excepto sus tareas.

1234
Nuevo comentario