Me pregunto cómo funciona el diseño receptivo junto con el principio de Separaciones de preocupación, con respecto a cómo permitimos que una implementación única se comporte para múltiples dispositivos de presentación (móviles, tabletas, tamaños de navegador, etc.). ¿Está rompiendo el principio?
Si hago cambios en una página web que sé que se comporta de manera receptiva y debería funcionar en 5 dispositivos, por ejemplo, ¿no estoy haciendo el desarrollo extremadamente difícil debido a la posible regresión que puede ocurrir desde un solo lugar en el software?
Claro que me está haciendo escribir menos código y trabajar mucho más rápido en múltiples dispositivos, pero ahora cada una de mis páginas requiere pruebas potencialmente mucho más exhaustivas, que es el costo que podría pasar para no usar un marco web receptivo y mantener implementaciones separadas de un página.
fuente
Respuestas:
La forma en que está viendo la capacidad de respuesta va en contra del principio de separación de preocupaciones. Su pregunta supone que la capacidad de respuesta es una responsabilidad única que solo pertenece a un componente.
Sugeriría que la capacidad de respuesta es un atributo / responsabilidad que se puede aplicar a múltiples componentes. Por el bien de mi ejemplo, estoy asumiendo un MVC genérico | MVP | Patrón de tipo MVVM.
La Vista ciertamente tiene una mano en la capacidad de respuesta de la aplicación. Los elementos y la lógica de la interfaz de usuario que usa dictan cómo funcionará la vista. Entonces, View es responsable de la capacidad de respuesta de los elementos de la interfaz de usuario.
El controlador también participa en la capacidad de respuesta de la aplicación. Los tipos de estructuras de datos y cómo se elabora la lógica empresarial afectarán el rendimiento. Entonces aquí, el controlador | Presentador | ViewModel también tiene la responsabilidad de la capacidad de respuesta. Pero esta responsabilidad es sobre elementos diferentes de los que la Vista es responsable.
Finalmente, el Modelo es responsable del acceso a datos / llamadas de servicio. Hay consideraciones obvias de rendimiento en cómo se recuperan los datos y se presentan a la capa intermedia. Pero, de nuevo, este es un elemento diferente que también debe ser receptivo.
Responsivenesscomo propiedad no es responsabilidad única de ningún componente. Todos los componentes deben ser responsables de su propia elaboración para contribuir a la aplicación general. Una gran interfaz de usuario y controlador pueden volverse inútiles mediante solicitudes de datos aparentemente interminables.En cuanto a las pruebas, el uso de un enfoque escalonado aún funciona a su favor con respecto al esfuerzo general y la capacidad de respuesta. Si tiene 5 dispositivos y escribió capas individuales para cada dispositivo, tendría 15 componentes para probar. El uso del patrón MVC * le permite eliminar 8 componentes de la prueba ya que tiene un Modelo y un Controlador comunes. Si esas dos capas realizan su parte del trabajo de manera receptiva, entonces solo tiene que probarlas una vez. Luego puede concentrar sus esfuerzos restantes en las 5 Vistas.
fuente
No creo que viole la separación de preocupaciones ya que el CSS utiliza consultas de medios para separar el estilo para un tamaño de pantalla en particular. Las consultas de medios encapsulan el código para un tamaño de pantalla particular.
Creo que, en lugar de pensar que el diseño receptivo funciona para un número X de dispositivos, se debe considerar que el diseño receptivo funciona para todos los tamaños de pantalla. Es la misma página web, acaba de diseñar el tamaño de la pantalla.
fuente