oracle - tecnica - Uso de componentes conscientes de datos de Delphi: ventajas y desventajas

metodo delphi ventajas y desventajas (7)

Descubrí que el uso de componentes que tienen en cuenta los datos da como resultado una aplicación sin distinción clara entre el negocio y la lógica de UI.

Esto está bien para proyectos pequeños, pero a medida que crecen, el código se vuelve cada vez menos mantenible.

¡Todos los diversos bits de código de evento (y sus interacciones) pueden convertirse en una verdadera pesadilla para comprender!

Invariablemente, en tales casos, he abandonado los componentes que reconocen datos y he cambiado a un diseño MVC (codificado a mano).

Esto requiere una gran cantidad de esfuerzo de codificación inicial, pero los resultados (IMHO) en un proyecto que se puede mantener, es extensible y se puede depurar.

Quiero saber su opinión sobre el uso de componentes conscientes de datos en proyectos. ¿Cuáles son los puntos ''fuertes'' y ''débiles'' del desarrollo de aplicaciones (win32 y web), mediante el uso de Delphi y los componentes sensibles a los datos (de la suite estándar de Delphi o de terceros)?

Usando FireBird, he trabajado mucho con IBObjects, que son un conjunto de componentes maduro y funcionó muy bien.

Pero también hay muchos otros RDBMS (MySQL, MSSQL, DB2, Oracle, SQLite, Nexus, Paradox, Interbase, FireBird, etc.). Si ha desarrollado grandes proyectos, en los que ha utilizado muchos componentes que tienen en cuenta los datos, responda con el tipo de base de datos y el nombre de la suite con componentes para datos.

También estoy interesado en DB2 (AS400). ¿Qué componentes ha utilizado con éxito, o con qué componentes es realmente difícil trabajar?

Después de haber probado el estilo de aplicaciones Delphi tanto para datos como para datos, estoy de vuelta en el campamento de componentes conscientes de datos en estos días. Se necesita un poco de trabajo y disciplina para colocar correctamente el código en capas, pero aún así es más rápido que hacerlo todo a mano utilizando controles que no tienen en cuenta los datos.

Algunos de mis consejos para el uso de componentes conscientes de los datos son

No solo reescriba FishFact en una escala más grande. Piense un poco en su diseño.
No use un TDataModule, use muchos TDataModules, cada uno responsable de solo un pequeño aspecto de los datos de sus aplicaciones.
Los conjuntos de datos TDatas pertenecen a TDataModules, mientras que los datos TData pertenecen a TForms (a menos que se utilicen para relaciones maestro / detalle).
Use conjuntos de datos en memoria como el DataSnap TClientDataSet.
Sus ClientDataSets no tienen que reflejar exactamente las tablas de su base de datos. DataSnap le permite masajear sus estructuras de datos en la memoria para que pueda producir conjuntos de datos personalizados para propósitos específicos. Específicamente puedes hacer cosas como
- Unir dos o más tablas en un conjunto de datos editable
- La desnormalización de las estructuras de la tabla maestra de detalles, puede simplificar su código UI a veces.
- Cree campos solo en memoria (como campos calculados, pero también puede escribir en ellos)
Las tablas anidadas de TClientDataSet son útiles, pero no son la única forma de expresar relaciones de detalle maestro. A veces es mejor hacerlo de la manera anterior con dos TClientDataSets independientes unidos a través de un TDataSource.

Eche un vistazo a las soluciones ORM.

Es un buen enfoque con la arquitectura de varios niveles. Ver ORM para DELPHI win32

Los componentes conscientes de los datos son útiles desde una perspectiva de RAD y creación de prototipos, especialmente cuando se diseñan informes o cuadrículas basadas en datos. es decir, se puede jugar en el tiempo de diseño. Así que los uso así. Pero cuando llega el momento de transformarlo en código de envío, casi siempre rompo las conexiones, elimino el SQL de las consultas y hago todo lo que está en el código. Es mucho más predecible y mantenible de esa manera, especialmente en un entorno de múltiples desarrolladores con control de versiones. Cuando el SQL está incrustado en el formulario en algún lugar, es un gran dolor tratar de averiguar dónde reside realmente el SQL. Y es especialmente malo tener SQL en dos lugares, y luego tener que averiguar cuál está vigente.

Los componentes de Delphi que tienen en cuenta los datos no dependen del motor de base de datos de back-end que está utilizando, por lo que el uso de Firebird o MS SQL Server u Oracle u otros no son importantes para sus componentes que tienen en cuenta los datos. Solo conocen el componente de fuente de datos que se les asigna y hacen todo lo relacionado con su base de datos a través de eso.

Para mí, si se puede hacer algo con componentes que tengan en cuenta los datos de una manera agradable, los usaré. Estos son generalmente pequeños proyectos que deben hacerse en un corto tiempo. En proyectos más grandes, podría descartar por completo los componentes conscientes de los datos o usarlos en formularios que se utilizan simplemente para la presentación de datos y no reciben comentarios del usuario. Cuando se trata de recibir comentarios del usuario, es posible que use componentes que no reconocen datos porque tengo más flexibilidad para controlarlos y validar los comentarios. Por supuesto, los componentes de dataware también pueden ser útiles en tales escenarios. Aún puede validar la entrada del usuario en eventos de conjuntos de datos como OnBeforePost. Además, si está utilizando un diseño de múltiples niveles, y su aplicación cliente representa la capa del presentador de datos, su validación de entrada se realiza en el nivel medio para que pueda recibir información utilizando componentes conscientes de los datos en la aplicación cliente y enviarlos a la Nivel medio para la validación y posterior procesamiento.

Los controles conscientes de los datos son excelentes, pero debe asegurarse de obtener su código de negocio en una capa separada.

Eso no es difícil, pero debe ser consciente de cómo puede hacerlo.

Un enfoque es tener sus componentes DataSet en un DataModule (u otro contenedor no visual).

Otro truco útil es usar un TClientDataSet para realizar la entrada de la interfaz de usuario y usarlo como un búfer intermedio entre la interfaz de usuario y la capa empresarial. La capa empresarial luego utiliza componentes TDataSet específicos para su capa de datos.

--geno

Puede usar Unidac que es compatible con muchos servidores de bases de datos, incluido Firebird (que yo uso) y tiene muy buenas características.

Junto con Remobject SDK , tendrá una buena combinación de arquitectura de n niveles y abstracción de base de datos.