Al desarrollar un sistema o aplicación que planea usar con un determinado marco, ¿es mejor diseñar el sistema sin el marco en mente, o es mejor diseñar el sistema con la mentalidad? "Bueno, el marco tendría un tiempo más fácil con este".
development-process
systems
Robert Pounder
fuente
fuente
Respuestas:
Su diseño debe satisfacer las necesidades de los clientes lo más cerca posible. Recuerde que el diseño incluye pequeñas cosas como:
Ninguna de estas cosas debe ser dictada por el marco. Si está claro que lucharás contra tu marco para lograr estos objetivos, entonces eliges un nuevo marco que te ayudará a lograr esos objetivos antes de comenzar a escribir código.
Una vez que haya elegido un conjunto de herramientas apropiado (el marco es una herramienta), le recomiendo usar las herramientas de la forma en que están diseñadas para ser utilizadas. Cuanto más se desvíe del diseño del marco, más aumentará la curva de aprendizaje para su equipo y mayores serán las posibilidades de que algo salga mal.
En breve
Pensamientos adicionales:
Después de más de 20 años de ingeniería de software y utilizando varios marcos, he aprendido un par de lecciones. Todos los marcos son un arma de doble filo: ambos limitan y habilitan. El problema con la decisión de su marco antes de mirar los 3 grandes que mencioné anteriormente es que podría estar comprometiendo una buena experiencia de usuario para una mediocre (en el mejor de los casos). O puede verse obligado a desviarse del diseño de marcos para lograr alguna funcionalidad específica.
fuente
Los marcos influyen naturalmente en el diseño de módulos y subsistemas específicos (como una interfaz gráfica de usuario). Como se mencionó en la otra respuesta, tendrá un momento difícil si se encuentra luchando contra los marcos elegidos.
Sin embargo, en términos más generales, debe evitar dejar que un solo marco o tecnología dicte o impulse el "panorama general" de la arquitectura general del sistema. La mayoría de los marcos de aplicaciones de uso general no fomentan esto, así que si te encuentras escribiendo todo tu sistema alrededor de un marco, entonces probablemente estés haciendo algo que los autores de ese marco no tenían la intención.
Probablemente usará muchos marcos diferentes para resolver diferentes problemas; A medida que su sistema se vuelve más complejo, debe tener cuidado de no construir The Big Ball Of Mud . Siempre que sea posible, mantenga su sistema modular y sin apretar. Algunos frameworks pueden mantenerse mejor detrás de las abstracciones escribiendo envoltorios y adaptadores que 'oculten' los flujos de trabajo específicos de Framework lejos de otros componentes. Los kits de herramientas de la GUI tienden a servir solo a la funcionalidad de la GUI front-end, por lo que esos módulos de la GUI deben mantenerse alejados del resto del sistema.
Los marcos de uso general (como los marcos de UI, los marcos de capa de datos, etc.) no existen para prescribir la arquitectura completa de su sistema; a lo sumo, pueden prescribir el diseño de un componente o módulo; por ejemplo, algunas tecnologías GUI están orientadas a patrones MV * particulares.
La arquitectura general de su sistema debe estar impulsada principalmente por los requisitos de su negocio. . Puede encontrarse apoyado en gran medida en una herramienta en particular (por ejemplo, una herramienta de middleware de mensajería o un marco ORM) para unir todo, pero si ha encapsulado el marco en una abstracción como una clase de 'servicio', usted es menos probable que te encuentres limitado por ese marco cuando encuentres sus limitaciones.
Intente tener en cuenta lo siguiente para su diseño de imagen general:
fuente
Sí, debe atenerse lo más posible a lo que el marco "le dice" que haga.
La razón es simplemente que cuanto más se apegue a la forma de "pensar" de los marcos, más fácil será hablar con otros desarrolladores sobre sus problemas / ideas que también usan ese marco.
Aumenta la interoperabilidad y la facilidad de uso para otras personas que lo usan más tarde, comprenderá e incorporará tutoriales o soluciones comunes mejor si se apega a la filosofía subyacente de lo que esté usando.
La única buena razón por la que puedo pensar por qué "rompería" el marco es que necesita absolutamente algo que no puede proporcionar dada su configuración / aplicación "predeterminada" de principios. Pero entonces, podría no ser el marco adecuado para comenzar.
Básicamente, esto también puede aplicarse a otras decisiones. Se debe utilizar la lengua que está utilizando en la mayor medida que está destinado a ser utilizado, porque hace las cosas más fáciles si se habla el mismo idioma que todos los demás.
fuente