Discusión sobre el artículo "Plantilla para proyectar el MVC y posibilidades de uso" - página 2
Está perdiendo oportunidades comerciales:
- Aplicaciones de trading gratuitas
- 8 000+ señales para copiar
- Noticias económicas para analizar los mercados financieros
Registro
Entrada
Usted acepta la política del sitio web y las condiciones de uso
Si no tiene cuenta de usuario, regístrese
Resulta ser mucho más complicado que eso - MVC , MVP , MVVM hub: https: //habr.com/ru/post/215605/
Si crees en el hubr, el autor tiene razón, en MVC un modelo no debe saber (depender de) nada excepto sus tareas.
Bueno, claro que lo tengo todo bien dicho )))). Pero MVC no es muy exigente con la disciplina, lo que personalmente me gusta especialmente
MQL es "experto" en el trabajo con estructuras (constructor de copias, trabajo con archivos, trabajo con SQLite).
¿Es realista utilizar la plantilla MVC de tal manera que la interacción se organice a través de algunas estructuras de estado/parámetro? es decir, pasar estas estructuras por referencia. ¿O necesitamos otra plantilla?
Es muy real. Es un buen camino. Más arriba se hizo una observación en este sentido. Pero es mejor intercambiar referencias no a algunas estructuras, sino a los propios componentes. Por ejemplo, una vista puede necesitar acceso a un modelo. Y el modelo puede proporcionar métodos para acceder a ciertos objetos/estructuras o submodelos más grandes. Sólo recuerde que la vista no debe cambiar el modelo. Por lo tanto, el acceso debe ser apropiado.
Es muy real. Es un buen camino. El comentario anterior iba precisamente en esa dirección.
Se necesita un ejemplo
o mejor artículo.... justo y el manejo de errores del servidor se puede hacer
ejemplo
o mejor aún, un artículo.... se puede hacer precisamente eso y la gestión de errores del servidor
Bueno, en principio se puede ) Hacer la segunda parte no a nivel primitivo, sino a nivel real, de trabajo. Me lo pensaré. No quiero crear artículos en el mismo sitio, se reirán.
Haz la segunda parte no a un nivel primitivo, sino a un nivel real, de trabajo.
Creo que sería práctico para todos.
y para no inflar el articulo en ciento cincuenta secciones sobre manejo de errores, creo que es suficiente con manejar 1-2 errores de servidor (envio/cierre de ordenes) y 1-2 errores de terminal(obtener precios/tiempos actuales?....).
Bueno, y usar estructuras tanto como sea posible es relevante para mi, sospecho que tanto los errores como guardar el estado de EA pueden ser eficientemente organizados en un archivo binario usando estructuras.
¿Leíste 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 la forma presentada, sólo para la comprensión de la mayoría. Y la forma que sugieres implica el mismo acceso incontrolado a los objetos globales, solo que desde un lado.
Por lo visto no te has dado cuenta de que ya me he referido a tus excusas en el artículo en mi comentario.
A la mayoría de la gente se le enseña cómo no hacer las cosas, no MVC u OOP. Y la frase resaltada en verde sólo refleja tu errónea comprensión de cómo debe implementarse.
Por lo visto no te diste cuenta de que eran tus excusas en el artículo a las que ya me refería en mi comentario.
Enseñas a la mayoría cómo no hacer las cosas, no MVC u OOP. Y la frase resaltada en verde sólo refleja tu erróneo entendimiento de cómo debe implementarse.
¿Estás seguro de que esto es lo que vale la pena discutir en los comentarios del artículo?
Cuanto le gusta a nuestro foro este tipo de expresiones / consejos, me asombra )))). Por cierto, yo serví en esas partes, era medio día de camino a China )
¿Estás seguro de que merece la pena discutir esto en los comentarios del artículo?
¿por qué no? toma nota, arréglalo en el próximo.