Hola,
Comentar, que es mi opinión y no está basada en una documentación técnica (puesto que yo soy autodidacta
), sino, en mi experiencia al trabajar con esta técnica, por lo cuál puedo equivocarme fácilmente.
Igualmente quisiera dejar claro que soy partidario de trabajar con estos componentes, y es obvio ya que todos mis proyectos los
fabrico con dbExpress + DataSnap.
Considero que es más lento por una sencilla razón: para obtener los mismos resultados utilizamos mayor número de procesos.
Disculpen que esto pueda ser un poco espeso:
Suponiendo que utilizamos Socket Server:
El usuario solicita registros -> ClientDataset -> SocketConnection (empaquetado y codificación de la petición) ->
Transmisión por Internet o red -> Socket Server (desempaquetado de petición, interpretación) -> Servidor SQL -> tDatasetProvider -> tSLQDataset -> Servidor BD (apertura de cursor y retorno de TODOS los registros solicitados). -> tSQLDataset -> tDatasetProvider -> Servidor SQL (Empaquetado de todos los registros, incluyendo estructura de campos, restricciones, etc. Esto se hace con un Whlile para recorrecorer todos los registro y por cada registro un For para recorrecr todos los campos de la consulta y añadiendolos al paquete que se retornará) -> Socket Server (interpretación y retorno al la capa Cliente) ->
Transmisión por Internet o red (un solo paquete indistintamente de su tamaño, provocando posibles cuellos de botella, demoras, etc) -> SocketConection (interpretación, desempaquetado, de nuevo While's y for...) -> ClientDataset (resultado de la consulta cargada en memoria Ram, muchos ClientDataset, con muchos registros: consumo de recursos - Desbordamiento de memoria Ram) ->
presentación de datos al usuario.
Posibles errores:
Son muchos los inconvenientes de una mala gestión de esta tecnica.
Realmente lo que tenemos en un ClientDataset es una copia de los registros que hipoteticamente tenemos en la BD. Si por algún motivo se manipulan los datos en la BD (procedimientos almacenados, triggers, otros usuarios) podemos obtener error de conciliación de datos.
La complicación real, está en que hay conocer muy bien como funciona un modelo en tres capas para desarrollar correctamente nuestro software.
Si pasamos a programar de 2 a 3 capas el programador tendrá
inventar nuevas técnicas para realizar procesos que eran muy simples en 2 Capas (como puede ser la asignación de valores a los campos
PRIMARY KEY de las tablas)
No obstante, no me mal interpreten, con una tecnica muy depurada recomiendo fabricar aplicaciones en 3 capas antes que en 2 capas.
Pero, simplemente es mi opinión.
Un Saludo.