Uso de componentes con reconocimiento de datos Delphi: pros y contras

Question

Quiero saber su opinión sobre el uso de componentes con capacidad 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 componentes con capacidad de datos (del paquete estándar de Delphi o de un tercero)?

Uso de FireBird He trabajado mucho con IBObjects, que son un conjunto maduro de componentes 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 con capacidad de datos, responda con el tipo de base de datos y el nombre del conjunto de componentes con capacidad de datos.

También estoy interesado en DB2 (AS400). ¿Qué componentes ha utilizado con éxito o qué componentes son realmente difíciles de manejar?

Answer 1

He encontrado que el uso de los componentes con capacidad de datos da como resultado una aplicación sin una distinción clara entre la lógica empresarial y la de la interfaz de usuario.

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

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

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

Esto requiere mucho esfuerzo de codificación inicial pero los resultados (en mi humilde opinión) en un proyecto que es mantenible, extensible y depurable.

Answer 2

Eche un vistazo a las soluciones ORM.

Es un enfoque agradable con arquitectura de varios niveles. Ver ORM for DELPHI win32

Answer 3

Los componentes Delphi con reconocimiento de datos no dependen del motor de base de datos back-end que esté utilizando, por lo que el uso de Firebird o MS SQL Server u Oracle u otros no tiene importancia para sus componentes de datos. Solo conocen el componente de origen de datos asignado a ellos y hacen todo su material relacionado con DB a través de eso.

Para mí, si se puede hacer algo con componentes compatibles con datos de una manera agradable, los usaré. Por lo general, estos son proyectos pequeños que se deben realizar en poco tiempo. En proyectos más grandes, podría descartar totalmente los componentes con capacidad de datos o usarlos en formularios que simplemente se usan para la presentación de datos y no reciben información del usuario. Cuando se trata de recibir información del usuario, podría usar componentes que no tengan en cuenta los datos porque tengo más flexibilidad para controlarlos y validar la entrada. Por supuesto, los componentes de data ware también pueden ser útiles en tales escenarios. Todavía puede validar la entrada del usuario en eventos de conjunto de datos como OnBeforePost. Además, si usa un diseño de varios niveles y su aplicación de cliente representa la capa de presentador de datos, la validación de su entrada se realiza en el nivel intermedio para que pueda recibir información utilizando componentes de datos en la aplicación cliente y enviarlos al nivel medio para validación y procesamiento posterior.

Answer 4

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

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

Answer 5

Los componentes sensibles a 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, puedes jugar el tiempo del diseño. Entonces los uso así. Pero cuando llega el momento de transformarlo en código de envío, casi siempre corto las conexiones, elimino el SQL de las consultas y hago todo 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 alguna parte del formulario, es un gran problema tratar de descubrir dónde reside realmente el SQL. Y es especialmente malo tener SQL en dos lugares, y luego tener que descubrir cuál está en efecto.

Answer 6

Los controles de datos son geniales, pero debe asegurarse de obtener el código de su empresa en una capa separada.

Eso no es difícil, pero debe saber cómo hacerlo.

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

Otro truco útil es usar un TClientDataSet para hacer la entrada de la interfaz de usuario, y usar eso como un búfer intermedio entre la interfaz de usuario y la capa de negocios. La capa de negocios luego usa componentes TDataSet específicos de su capa de datos.

--jeroen

Answer 7

Habiendo probado tanto el estilo-consciente de los datos y no de reconocimiento de datos de aplicaciones Delphi estoy de vuelta en el campo de los componentes de reconocimiento de datos en estos días. Se necesita un poco de trabajo y disciplina para aplicar una capa correcta al código, pero es aún más rápido que hacerlo todo a mano con controles que no tienen en cuenta los datos.

Algunos de mis consejos para el uso del componente de reconocimiento de datos son

• No se limite a reescribir FishFact en una escala más grande. Pon algo de reflexión en tu diseño.

• No utilice un TDataModule, utilice muchos TDataModules, cada uno de los cuales es responsable de solo un pequeño aspecto de los datos de sus aplicaciones.

• TDatasets pertenecen a TDataModules, mientras que TDataSources pertenecen a TForms (a menos que se utilicen para las relaciones maestro/detalle).

• Utilice conjuntos de datos en memoria como DataSnap TClientDataSet.

• Sus ClientDataSets no tienen que reflejar exactamente las tablas de su base de datos. DataSnap le permite dar masajes a sus estructuras de datos en la memoria para que pueda producir conjuntos de datos a medida para fines específicos. Específicamente se pueden hacer cosas como

  • unir dos o más tablas en la base de datos editable uno

  • desnormalización estructuras de la tabla maestro detalle, puede simplificar el código de interfaz de usuario a veces.

  • Crear en memoria sólo los campos (como los campos calculados, pero se puede escribir en ellos también)

• TClientDataSet tablas anidadas son útiles, pero no es la única manera de expresar las relaciones maestro detalle. A veces es mejor hacerlo de la manera antigua con dos TClientDataSets independientes unidos a través de un TDataSource.