design - software - ¿Diseñar desde la base de datos hasta la interfaz de usuario o de otra manera?
que es interfaz pdf (11)
¿Siempre te inclinas a pensar en el esquema db cuando comienzas o planeas un nuevo proyecto o vas por el otro camino y comienzas a diseñar UI y luego a bajar la pila?
¿O tienes una forma diferente de desarrollar?
No es realmente una pregunta ágil / cascada / especificaciones / historias, solo una manera de obtener una idea de la forma en que las personas se inclinan cuando trabajan en proyectos personales / profesionales o de otro tipo.
He decidido que ambas son las mejores maneras en el pasado y actualmente estoy en el primer campamento de UI, pero eso puede cambiar y lo hará.
Saludos John
Básicamente, averiguo qué se supone que es la funcionalidad primero. No me ocupo de la interfaz de usuario o de cómo se ve o cómo se supone que se debe ingresar, me ocupo de lo que el usuario quiere hacer.
Luego construyo un modelo de datos alrededor de eso. A veces es un modelo de datos muy simple (especialmente si es un requisito simple como "reproducir una película"), otras veces es muy complejo.
Solo después de que se decida esto, trato de diseñar una interfaz de usuario que refleje tanto el modelo como la forma en que el usuario espera que la información de entrada funcione.
Toma eso por lo que quieras; me funciona de manera bastante efectiva.
Diseña primero tus pantallas de esa manera sabes lo que necesitas en la base de datos.
Si comienza con la base de datos, generalmente comienza con una serie de suposiciones sobre cómo funcionará la aplicación.
En los proyectos en los que trabajo, encuentro que la IU es de donde provienen muchos de mis requisitos: es la parte que al usuario final le importa (o al menos piensa).
Esto parece ser muy situacional. Con el trabajo que hago, la mayoría del trabajo comienza en la base de datos, porque las bases de datos en las que trabajo son recursos de la empresa, que son utilizadas por múltiples UI. Sería perjudicial tener el DB diseñado en torno a los caprichos de una IU específica que probablemente cambiará a menudo.
Por otro lado, hay situaciones en las que podría ser más beneficioso enfocarse en la IU, y dejar que el diseño de la base de datos venga más tarde, tal vez en una aplicación móvil DB incorporada, por ejemplo.
Generalmente, empiezo con la base de datos primero y construyo la interfaz de usuario para adaptarla. Por lo general, hay algunos vaivenes, ya que es posible que necesite cambiar la base de datos para que se adapte a los requisitos de la interfaz de usuario o viceversa.
Esta ruta, comenzando con la base de datos primero, es cómo me enseñaron en la escuela y me quedó grabada.
Un programador con el que trabajé comenzaría con la salida. Comenzaría por averiguar qué era necesario hacer (es decir, qué informes debían publicarse, etc.) y luego trabajaría con los datos necesarios para llegar allí. La interfaz de usuario y la base de datos se construyeron al mismo tiempo.
Hago ambos. Normalmente dibujo un prototipo de cómo se verá la pantalla y luego intento desarrollar un modelo de datos a partir de eso. En lugar de ir directamente a una base de datos, encuentro que esto funciona mucho mejor que con mi UI. Puedo ver la necesidad de propiedades (o campos en una base de datos) que de otro modo no habría pensado. A partir de ahí, desarrollo el modelo y me muevo hacia adelante y hacia atrás hasta que ambos se adapten a las necesidades del requisito y luego me preocupan los esquemas de la base de datos. Normalmente, aunque el modelo en sí mismo definirá el esquema para mí, eso se solucionó.
Modele el dominio primero, eso le dirá cómo construir su base de datos. Encuentre sus requisitos a continuación: ¿qué deben hacer los usuarios con la aplicación? Eso le dirá qué funcionalidad debe existir. Con eso en la mano, puede crear su esquema de BD y su modelo de software (ya sea OO, funcional, o lo que sea, tendrá la información necesaria). ENTONCES crea una interfaz de usuario bonita que expone la funcionalidad que construiste; por supuesto, la construcción de la interfaz de usuario se puede sincronizar también con la funcionalidad, pero ambas deben venir después de determinar cómo se ve el dominio.
Para el usuario promedio, la interfaz de usuario es el software. No les importa cómo se almacenan los datos, qué plataforma usa, etc. Por lo tanto, si su software será utilizado por personas, recomiendo comenzar con una IU, ya sea un prototipo o maquetas. Muéstrele eso a los usuarios y obtenga comentarios. Luego construya la capa empresarial y la capa de datos.
Encuentro que esto ayuda a reunir los requisitos. Los usuarios no técnicos son mucho más propensos a decirle "oh, espera, necesitamos otro campo en esta página" que "necesitamos otro atributo en este esquema de tabla". También pueden decir "necesitamos otro botón aquí", que generalmente se traduce en alguna lógica comercial adicional, etc.
Recientemente dejé de diseñar mi modelo de datos primero. Trabajé con un desarrollador que me ayudó a desarrollar Domain Driven Design. Ahora me siento y diseño primero mi modelo de Dominio, y luego mi modelo de datos. al mismo tiempo, tomo en consideración cualquier desafío que pueda presentar la UI.
Tiendo a comenzar en el medio y averiguar qué hará la aplicación y cómo, rebotar entre la interfaz de usuario y el diseño de la base de datos, ya que pueden informarse entre sí.
sobre todo, concéntrese primero en garantizar que el sistema resuelva el problema que se pretende resolver.
reunir los requisitos para definir el flujo de trabajo, los datos, las complejidades de la interacción del usuario, etc., y luego construir desde allí.
por supuesto, siempre tendrás que modificar cosas aquí y allá, pero a partir de mi experiencia, encuentro que las personas que se suscriben a una filosofía u otra (es decir, siempre comienzan desde la base de datos y acumulan vs. ui y se sumergen) muchas veces terminan con una solución que no se ajusta al problema.