¿Diseñar desde la base de datos hasta la interfaz de usuario o de otra manera?

Question

¿Siempre te inclinas a pensar en el esquema db cuando comienzas o planificas un nuevo proyecto o vas por el otro camino y comienzas a diseñar UI y luego a bajar la pila?

¿O tiene una forma diferente de desarrollar?

No es realmente una pregunta ágil/cascada/especificaciones/historias solo una forma de obtener una idea de cómo se inclina la gente cuando se trabaja en proyectos personales/profesionales o de otro tipo.

He decidido que ambas son las mejores formas en el pasado y actualmente estoy en el primer campamento de UI, pero eso puede cambiar y lo hará.

Saludos John

Answer 1

Hago ambas cosas. Normalmente dibujo un prototipo de cómo se verá la pantalla y luego trato de 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ó.

Answer 2

la disposición de su primera pantallas de esa manera usted sabe lo que necesita 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.

Answer 3

Tiendo a comenzar en el medio y averiguar qué hará la aplicación y cómo, luego rebotar entre la interfaz de usuario y el diseño de la base de datos, ya que pueden informarse entre sí.

Answer 4

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, quizás en una aplicación móvil DB incrustada, por ejemplo.

Answer 5

En general, comienzo 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 ajuste a los requisitos de la IU o viceversa.

Esta ruta, empezando por la base de datos primero, es como 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.

Answer 6

En los proyectos en los que trabajo, encuentro que la IU es de donde provienen muchos de mis requisitos: es la parte que le importa al usuario final (o al menos piensa).

Answer 7

Esencialmente, descubro que se supone que la funcionalidad es la primera. 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 haya decidido, trato de diseñar una interfaz de usuario que refleje tanto el modelo como la forma en que el usuario espera que la entrada funcione.

Toma eso para lo que quieras; me funciona de manera bastante efectiva.

Answer 8

sobre todo, concéntrese primero en garantizar que el sistema resuelva el problema que se pretende resolver.

reúne los requisitos para definir el flujo de trabajo, los datos, las complejidades de la interacción del usuario, etc., y luego construye desde allí.

por supuesto, siempre tendrá que modificar cosas aquí y allá, pero por mi experiencia encuentro que las personas que se suscriben a una filosofía u otra (es decir, siempre comienzan desde el DB y crean contra Ui y se sumergen) los tiempos terminarán con una solución que no se ajusta al problema.

Answer 9

Primero modele el dominio, que le indicará 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 interfaz de usuario compila puede hacerse sincronizada también con la funcionalidad, pero ambas deberían venir después de determinar cómo se ve el dominio.

Answer 10

Acabo de dejar de diseñar primero mi modelo de datos. 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.

Answer 11

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 UI, 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.

Me parece 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.