Cita:
|
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.