Cualquier sugerencia para separar el acceso a los datos, la lógica empresarial y la GUI en Delphi

Question

Quiero separar la capa de datos de la lógica de negocios y la lógica de negocios de la GUI. Al sumergirme en la red tropecé con algunos recursos pero todavía no podía despejar mi mente. Algunas personas hablan sobre patrones, otros señalan varios marcos. Mis requisitos son:

• manipular los datos de RDBMS (MySQL principalmente) las operaciones CRUD
• se trata de la generación de Identificación (debo usar incremento automático o en el motor de datos suministrado o código Pascal generado)
• Relaciones de tabla podrían ser lógicos (no se utiliza ninguna integridad referencial) o no
• necesidad de capacidad de generar relaciones de objeto de modelo de datos
• datos se deben convertir a objeto de negocio y la lógica de negocio manipulado
• componentes GUI existentes o de dominio público deben utilizarse

Lo que necesito es:

• algunos guiar técnicas/sugerencias con código de ejemplo básica/diseño de la aplicación (como las unidades-clases-modules-directorios) ... Siendo un experto en programación orientada a objetos que se confunden cuando tengo que diseñar la jerarquía de clases
• un marco sencillo con un tutorial
• o incluso su propio código/marco/enfoque diaria

Answer 1

Pruebe las fuentes abiertas InstantObjects y siempre querrá usar esto para todo tipo de programación de bases de datos en Delphi.

En IO deberá definir toda la estructura de datos en su interfaz y luego generará el código necesario para usted.

Solo pruébalo.

En cuanto a la generación de ID, confíe en MySQL para generar un ID de incremento automático para su. No gaste tiempo codificándolo.

Answer 2

Dado que está utilizando Delphi, asegúrese de mirar DataModules. Aquí es donde pone los componentes de acceso a la base de datos y la lógica.

Coloque las clases en archivos simples de "Unidad".

Haga que la interfaz de usuario hable con estos dos para que las cosas sucedan. Puede usar los componentes de acceso a la base de datos directamente en el formulario, pero esto se realiza mejor como un modo de "solo visualización" y utilizando el módulo de datos para realizar las operaciones en los datos. (Puedes hacer todo lo posible en el formulario para aplicaciones básicas, pero si quieres modularizar la aplicación, mantenerla separada es sensato).

Answer 3

Una forma simple de ayudar a hacer cumplir este tipo de separación es escribir pruebas unitarias para su lógica comercial. Además de los otros beneficios (sustanciales), hacer que el código sea comprobable significa que no puede (intencionalmente o no) estar estrechamente vinculado a la IU.

Intento (pero no siempre lo consigo) mantener los detalles de la capa de datos por separado mediante el uso de ClientDataSets independientemente de lo que se esté utilizando en el back-end (generalmente DBExpress o DBISAM). También intento escribir al menos algunas pruebas de integración para asegurarme de que la capa de datos funciona como se espera (base de datos de prueba separada con valores conocidos).

Con la lógica de negocios y los datos en su lugar (incluso parcialmente), la interfaz de usuario es mucho más directa. Y mantenible.

Answer 4

Un método que uso, y funciona muy bien, es intentar tomar diferentes rollos de su aplicación, y luego programar como si estuviera en ese rollo. Por ejemplo, cuando trabaja en la base de datos, ni siquiera piense en la GUI. En cambio, piense en exponer clases y métodos que simplemente funcionen con los datos. Si crea su propio SDK que luego consumirá, encontrará que el mantenimiento de este será mucho más fácil.

El desarrollo basado en pruebas es tu amigo. Conozca a DUnit y cree pequeñas pruebas concisas para ejercitar cualquier código no trivial. Documente las interfaces y cualquier cosa que no sea aparente mirando una pantalla llena de código.

Answer 5

Tome un vistazo a tiOPF

Answer 6

Personalmente utilizo tiopf para el modelo de negocio. Tiopf suministra la capa de acceso a datos. El último código del repositorio incluye un marco modelo-gui-mediador similar a MVC para mostrar el modelo. Esto le permite visualizar sus datos utilizando componentes delphi estándar.

Tiopf también incluye una serie de generadores de ID (guías, enteros de 32 bits y 64 bits, etc.).

Si está interesado en tiopf, le sugiero que empiece por mirar mi overview. Luego dirija cualquier pregunta a los grupos de noticias.

Answer 7

Echaré un vistazo a Model-View-Controller (que es una extensión del Observer/Patrón Observable). Esto significa que la 'vista' (es decir, la IU) solo sabe cómo actualizar los datos, y luego responde a los datos que se actualizan. El Modelo (u Observable) sabe cómo manipular datos y decir a Vistas que se ha actualizado. Esto significa que puede reemplazar la interfaz de usuario sin tener que cambiar el proveedor de datos, y viceversa.

Realice una búsqueda en Google, ya que hay muchos ejemplos de esto para Delphi (pero no tanto para Java/C#, etc.)