Crear Clases propias o Usar Existentes

[Neftali [Germán.Estévez]]

Empezado por roman

Similar a esto, he visto lo que menciona Wayne Niddery aquí pero no sé si es a eso a lo que te refieres.

Lo que comenta este párrafo es básicamente lo que intentaba explicar yo:

Moving data between controls and a data source in no way compromises an OO design because data sources (i.e. TDatasource) do not directly connect to a database and have absolutely no knowledge of the ultimate source or destination of the data that passes through them. Their only role is to provide a single point of connection for any number of individual data-aware controls. That single point of connection is to any descendant of the TDataset class.

Los controles de Base de Datos (TDBEdit, TDBCombo,...) no son el problema; La "miga" y la potencia está realmente en el TDataSet (DataLink); Además, derivado adecuadamente es el que te puede proveer de un FrameWork independiente del SGBD.

Y esto creo que da la respuesta:
Summary

Existing data-aware controls are perfectly compatible with well-designed object-oriented systems. The scorn placed on them by many has been misplaced; the real problem is the routing of data; data-aware controls hooked to datasets that have actual database connections is the problem since this allows data to flow around business logic instead of through it. But it is a problem solved easily by making your business classes responsible for creating the datasets seen by the presentation layer.

Se trata de que los componentes traten con un TDataSet y cortar el flujo de información entre el TDataSet y la Base de Datos, pasándolo al Gestor de Persistencia; Es el Gestor de Persistencia el que se comunica con el SGBD (en nuestro caso en lugar de vía TClientDataSet, como comenta el artículo, utilizando SQL).

A esto me refería con "no grabar de la forma estandard"; En el artículo habla de utilizar un ClientDataset, yo pensaba en SQL directamente.