You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
MVC (Modelo-Vista-Controlador) es un patrón en el diseño de software comúnmente utilizado para implementar interfaces de usuario, datos y lógica de control. Enfatiza una separación entre la lógica de negocios y su visualización. Esta "separación de preocupaciones" proporciona una mejor división del trabajo y una mejora de mantenimiento. Algunos otros patrones de diseño se basan en MVC, como MVVM (Modelo-Vista-modelo de vista), MVP (Modelo-Vista-Presentador) y MVW (Modelo-Vista-Whatever).
58
+
MVC (Modelo-Vista-Controlador) es un patrón en el diseño de software comúnmente utilizado para implementar interfaces de usuario, datos y lógica de control. Enfatiza una separación entre la lógica de negocios y su visualización. Esta "separación de preocupaciones" proporciona una mejor división del trabajo y una mejora de mantenimiento. Algunos otros patrones de diseño se basan en MVC, como MVVM (Modelo-Vista-VistaModelo), MVP (Modelo-Vista-Presentador) y MVW (Modelo-Vista-Whatever).
59
59
60
-
Las tres partes del patrón de diseño de software MVC se pueden describir de la siguiente manera:
60
+
El patrón Modelo-Vista-Controlador (MVC), es uno de los primeros que se debería aprender. Es tan fundamental que ha sobrevivido décadas en la industria y sus ideas se han esparcido por muchas plataformas. Es el padre de muchos otros patrones derivados como MVVM (Modelo-Vista-VistaModelo), entre otros.
61
61
62
-
* Modelo: Maneja datos y lógica de negocios.
63
-
* Vista: Se encarga del disseño y presentación.
64
-
* Controlador: Enruta comandos a los modelos y vistas.
62
+
image::mvc1.png[MVC]
63
+
64
+
Este patrón es esencial debido a que ayuda a responder una de las preguntas más comunes: _¿Dónde debería poner esta pieza de código?_.
65
+
66
+
El patrón _MVC_ es uno de arquitectura. Entrega un mapa de la estructura de la aplicación y como su nombre dice, consiste en tres capas: modelo, vista y controlador.
67
+
68
+
El siguiente diagrama de Apple muestra un poco la relación de las vistas y controladores.
El principal problema de MVC y por qué razón nacieron otros patrones derivados es debido a la tendencia de que los controladores crecían de forma exponencial. Incluso llegando a ser llamado Massive View Controllers, por la cantidad de responsabilidades que tenían que cumplir.
65
75
66
76
==== Modelo
67
77
68
-
El modelo define qué datos debe contener la aplicación. Si el estado de estos datos cambia, el modelo generalmente notificará a la vista (para que la pantalla pueda cambiar según sea necesario) y, a veces, el controlador (si se necesita una lógica diferente para controlar la vista actualizada).
78
+
La capa modelo (_model_), es la capa que maneja los datos y la lógica de negocios, independiente de su representación visual. Define qué datos debe contener la aplicación. Si el estado de estos datos cambia, el modelo generalmente notificará a la vista (para que la pantalla pueda cambiar según sea necesario) y, a veces, el controlador (si se necesita una lógica diferente para controlar la vista actualizada).
69
79
70
80
Volviendo a nuestra aplicación de lista de compras, el modelo especificará qué datos deben contener los artículos de la lista (artículo, precio, etc.) y qué artículos de la lista ya están presentes.
71
81
72
82
==== Vista
73
83
74
-
La vista define cómo se deben mostrar los datos de la aplicación.
75
-
76
-
En nuestra aplicación de lista de compras, la vista definiría cómo se presenta la lista al usuario y recibiría los datos para mostrar desde el modelo.
84
+
La capa vista (_view_) es la que muestra la información al usuario y permite interacciones, independiente de la capa de datos. La vista define cómo se deben mostrar los datos de la aplicación. En nuestra aplicación de lista de compras, la vista definiría cómo se presenta la lista al usuario y recibiría los datos para mostrar desde el modelo.
77
85
78
86
==== Controlador
79
87
80
-
El controlador contiene una lógica que actualiza el modelo y/o vista en respuesta a las entradas de los usuarios de la aplicación.
88
+
La capa controlador (_controller_) es la que actúa como puente entre modelo y vista. Almacena y manipula el estado de la aplicación y proporciona datos a las vista, interpreta las acciones del usuario según las reglas de negocio. El controlador contiene una lógica que actualiza el modelo y/o vista en respuesta a las entradas de los usuarios de la aplicación.
81
89
82
90
Entonces, por ejemplo, nuestra lista de compras podría tener formularios de entrada y botones que nos permitan agregar o eliminar artículos. Estas acciones requieren que se actualice el modelo, por lo que la entrada se envía al controlador, que luego manipula el modelo según corresponda, que luego envía datos actualizados a la vista.
83
91
84
92
Sin embargo, es posible que también se desee actualizar la vista para mostrar los datos en un formato diferente, por ejemplo, cambiar el orden de los artículos de menor a mayor precio o en orden alfabético. En este caso, el controlador podría manejar esto directamente sin necesidad de actualizar el modelo.
85
93
86
94
image::mvc.png[MVC]
87
95
96
+
=== Patrón Modelo Vista Vista-Modelo
97
+
98
+
El patrón Modelo-Vista-VistaModelo (_MVVM_), es un patrón de arquitectura que facilita estructurar la aplicación dividiéndola en tres roles.
99
+
100
+
image::mvvm.png[MVVM]
101
+
102
+
- El modelo (_model_): representa los datos y lógica de negocio de la aplicación.
103
+
- La vista (_view_): Muestra la información al usuario y permite la interacción.
104
+
- La vista-modelo (_view-model_): Actúa como puente entre las capas de vista y modelo. Contiene el estado de la vista y maneja la lógica de interacciones.
105
+
106
+
==== ¿Diferencias entre MVC y MVVM?
107
+
108
+
Al comparar los patrones de _MVC_ y _MVVM_ es notable la similitud y son casi idénticos.
109
+
110
+
La principal diferencia radica en que _MVC_ hace énfasis en los controladores. Encargados de manejar las interacciones para varias vistas. En cambio en _MVVM_ la vista-modelo es un único componente que controla el comportamiento y estado de una única vista. Comúnmente representado como un componente.
111
+
112
+
Otra diferencia es la forma de comunicación entre la vista y su controlador. En _MVC_ la vista y el controlador tienen funciones definidas que son llamadas de forma imperativa para informar sobre una acción o requerir actualizar la información en la vista. Por otra parte en _MVVM_ la vista y la vista-modelo están unidas por un mecanismo de enlazado (binding) que automáticamente informa sobre interacciones realizadas en la vista y cambios ocurridos en la vista-modelo. Estos mecanismos de enlazado varían según la plataforma.
113
+
114
+
Las capas de _MVC_ interactúan y son interpretadas dependiendo de algunos factores como:
115
+
116
+
- La plataforma donde se implementa.
117
+
- La experiencia del profesional y su interpretación del patrón.
118
+
- La moda del día (Los devs igual pueden seguir modas).
119
+
120
+
El patrón Modelo-Vista-VistaModelo (_MVVM_) es principalmente una versión de _MVC_ bajo un nombre diferente.
121
+
122
+
Si bien hay ligeras diferencias, perfectamente se pueden utilizar los conceptos de _MVC_ y _MVVM_ de forma unificada sin problemas.
123
+
124
+
=== La Importancia de MVC y MVVM
125
+
126
+
El utilizar un patrón de arquitectura como _MVVM_ con roles claramente definidos nos ayudan cumplir principios de diseño como la separación de conceptos. Lo que es una piedra angular para mantener código bien organizado, fácilmente entendible y que sus pruebas unitarias son viables de implementar.
127
+
128
+
Utilizar patrones de arquitectura como _MVVM_ es sumamente importante. A pesar de que los frameworks otorgen herramientas innovadoras para elaborar aplicaciones, si no utilizamos patrones de arquitectura el código se irá acumulando, aumentando de complejidad, para finalmente crear monolitos masivos que son difíciles de mantener y probar.
129
+
130
+
El hecho de que algunos frameworks manejen automáticamente la actualización de las vistas no justifica abandonar las buenas prácticas en el desarrollo de software que han existido por décadas en múltiples plataformas.
131
+
132
+
=== Más allá de MVC
133
+
134
+
Los patrones de arquitectura como _MVC_ y _MVVM_ tienen su foco en aplicaciones donde principalmente tenemos interacciones de usuario (UX), pero muchas veces las aplicaciones deben comunicar con servicios externos y otros elementos que necesitan otras formas de gestionar la arquitectura de código.
135
+
136
+
Para esto se recomienda utilizar patrones como los definidos en el Diseño Orientado a Dominio (Domain Driven Design) y arquitectura Hexagonal.
Copy file name to clipboardExpand all lines: book/chapters/systemd/chapter.adoc
+40Lines changed: 40 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -16,6 +16,44 @@ problemas de diseño de software con más confianza y aplicar principios de dise
16
16
17
17
El diseño de sistemas es un tema enorme. Cada uno tiene un enfoque diferente ya que no existen pautas paso a paso.
18
18
19
+
=== Estimación de Costos
20
+
21
+
Una estimación es un ejercicio de calcular los costos y requerimientos de un sistema de forma que se pueda tener una idea y referencia sobre el funcionamiento y costos futuros del mismo.
22
+
23
+
Estimar nos permite validar si la solución está dentro de los parámetros aceptables y analizar su factibilidad técnica y económica. La estimación es suficiente con que sea cercana al valor real, debido a que muchas variables pueden afectar los costos en el futuro.
24
+
25
+
Para poder estimar se necesitan algunas nociones y métricas básicas que pueden ser aplicadas a cualquier sistema.
26
+
27
+
==== Unidad de Volumen de Datos
28
+
29
+
El almacenamiento y transferencia de datos comunmente se mide en _Bytes_ y potencias de 2, debido a que un caracter _ASCII_ es 1 byte (8 bits).
30
+
31
+
La siguiente tabla muestra la unidad de volumen de datos.
32
+
33
+
|===
34
+
| Potencia | Valor Aproximado | Nombre | Abreviación
35
+
| 1 | 1 Uno (bit) | Bit | b
36
+
| 8 | 8 Ocho (bits) | Byte | B
37
+
| 10 | 1 Mil (bits)| Kilobyte | 1 KB
38
+
| 20 | 1 Millón (bits)| Megabyte | 1 MB
39
+
| 30 | 1 Mil Millón (bits)| Gigabyte | 1 GB
40
+
| 40 | 1 Billón (bits)| Terabyte | 1 TB
41
+
| 50 | 1 Cuatrillón (bits)| Petabyte | 1 PB
42
+
|===
43
+
44
+
==== Números de Latencia
45
+
46
+
La latencia nos indica cuánto se demora un proceso desde que se hace la petición hasta recibir una respuesta. A mayor cantidad de latencia, mayor será el tiempo que necesitemos esperar para obtener una respuesta. El tiempo de retraso de las latencias puede crear ineficiencias, especialmente en las operaciones en tiempo real.
47
+
48
+
Los siguientes gráficos contienen números aproximados, ya que según el avance tecnológico pueden variar con los años.
49
+
50
+
Basado en los números de Jeff Dean y Peter Norvig (http://norvig.com/21-days.html#answers).
51
+
52
+
53
+
image::latenciagrafico.png[Latencia Gráfico]
54
+
55
+
image::latencia.jpg[Latencia]
56
+
19
57
=== Escalado horizontal y vertical
20
58
21
59
La escalabilidad se refiere a la capacidad de una aplicación para manejar y soportar una mayor carga de trabajo sin sacrificar la latencia. Una aplicación necesita una potencia informática sólida para escalar bien. Los servidores deben ser lo suficientemente potentes para manejar mayores cargas de tráfico. Hay dos formas principales de escalar una aplicación: horizontalmente y verticalmente.
0 commit comments