DataSnap + IntraWeb
#1
Escrito 14 agosto 2013 - 08:55
Al día de hoy en la empresa donde trabajo se ha optado por el desarrollo Web con Intraweb + ADO (no es mi fuerte y mucho antes de mi contratación); la realidad es que como se han ido desarrollando las aplicaciones, a mi manera de ver, es totalmente ineficiente ¿Porqué esto? Debido a que cada Form (TIWAppForm) tiene incrustada la lógica de negocio; osea que a largo plazo será una lucha titanica la mantenibilidad de las aplicaciones.
Además de que Intraweb tiene la limitación para aplicaciones ISAPI (dll) de no soportar herencia visual de los formularios, a razón de esto si lo vemos desde el lado positivo te forza a programar orientado a objeto pero esto es todo un mito acá en la empresa, he desarrollado algunas clases cuando me dan tiempo y han podido constatar las bondades de dicha orientación.
Después de esta breve introducción de mi problema, mi intención es esperar a que se termine el desarrollo de las aplicaciones tal cual como esta y sugerir el desarrollo de una nueva versión de las aplicaciones amparado en DataSnap y obviamente Intraweb para orientar el desarrollo a objetos y consigo ganar las todas las bondades que esta ofrece.
Mi pregunta es ¿Algunos de ustedes han usado DataSnap para la Web (no necesariamente con Intraweb como cliente)?, ¿Cuál ha sido su experiencia en este entorno?. Conozco DataSnap de Delphi 7, no he usado el nuevo DataSnap 2009+, sé además de este hilo donde hay mucha documentación que tocara revisar.
P.D. Usamos Delphi 2010 como herramienta principal, aunque si debo sugerir una migración al menos a XE2 para obtener el DataSnap mejorado pues se hará, además de que la mayoría de documentación existente la basan en XE2.
Gracias de antemano.
#2
Escrito 14 agosto 2013 - 09:12
Yo también estoy interesado en este asunto.
Saludos
#3
Escrito 14 agosto 2013 - 12:08
¿Algunos de ustedes han usado DataSnap para la Web (no necesariamente con Intraweb como cliente)?
En lo personal, pienso que allí está la clave del asunto, en no usar IntraWeb. Yo tengo en producción varias aplicaciones desarrolladas con DataSnap que se comunican vía internet. Tengo perfectamente aisladas las reglas de negocio en el servidor DataSnap, dichos módulos jamás se enteran con que tipo de servidor o conexión van a trabajar; podría tratarse de un servidor WebBroker (vcl, consola o isapi) sobre Http, o bien un servidor DataSnap normal (vcl, consola o servicio) sobre TCP/IP, http o https. Tengo clientes "nativos" desarrollados con la vcl normal que trabajan de novela, estos no tienen ni la más remota idea acerca del tipo de Base de Datos ni de los componentes de conexión a esta, pues solo pasan parámetros y consumen métodos implementados en el servidor.
Hasta ahora no he tenido ningún problema a pesar de las dudas que surgieron a parir de este documento, aunque este solo habla de servidores Datasnap tipo REST, que hasta ahora no he utilizado en producción.
Cabe recordar que también es posible desarrollar clientes basados en librerías JavaScript (KendoUi , ExtJs, etc), puesto que Datasnap tiene un muy buen soporte para el intercambio de datos en formato JSON.
Un saludo.
#4
Escrito 14 agosto 2013 - 02:01
@egostar bienvenido a bordo, espero podamos compartir experiencia cuando toque.
@Wilson, muy agradecido por tu comentario, puedes decirme entonces que tipo de servidor tienes implementado con DataSnap ya que mencionas que no usas el tipo REST (pensé que era el ideal para aplicaciones web o conexiones vía Internet).
Otra pregunta, mencionas que las aplicaciones clientes solo consumen métodos publicados en el servidor, entiendo que es una de las funcionalidades propias del servidor, dichos métodos ¿Están en DataModule independientes? o mejor dicho ¿Como lo haces?.
Con respecto a Intraweb no es una decisión mía pero a nivel de desarrollo creo que Intraweb se comportaría como un "cliente" más que consumiría los métodos del servidor, por lo menos es lo que creo.
Gracias!!!
#5
Escrito 14 agosto 2013 - 04:10
Puedes decirme entonces que tipo de servidor tienes implementado con DataSnap ya que mencionas que no usas el tipo REST (pensé que era el ideal para aplicaciones web o conexiones vía Internet).
REST sería la mejor opción para "atender" clientes que van a correr desde un navegador, ya que solo soporta conexiones HTTP y HTTPS, yo no lo he usado en producción porque hasta ahora no he necesitado desarrollar ese tipo de clientes, y parece que la tendencia apunta a clientes nativos para diferentes dispositivos (mobiles, pcs, neveras, tvs, etc) de acuerdo al OS que utilicen, por eso en lo personal no he profundizado en desarrollar clientes que corran desde un browser.
Ademas de que con REST se pierde mucho de la versatibilidad y potencia de la interfaz IAPPServer (midas) que es la esencia del framework DataSnap y que anda de novela en aplicaciones Delphi nativas, me refiero a cosas como los Dataset anidados, el poder de los TClientDatasets, además de un largo etc.
Mi preferido es un Servidor Datasnap normal que puede correr como una aplicación vcl, de consola o como un servicio, este tipo me permite conexiones http/s y TCP/IP, solo necesito darle al cliente nativo, la ip del servidor y el puerto y listo.
Otra pregunta, mencionas que las aplicaciones clientes solo consumen métodos publicados en el servidor, entiendo que es una de las funcionalidades propias del servidor, dichos métodos ¿Están en DataModule independientes? o mejor dicho ¿Como lo haces?.
Cuando digo que mis clientes solo consumen métodos publicados en el servidor, me refiero a que hay incluso una forma más sencilla y directa de hacer una tarea, por ejemplo una inserción en una tabla, podría simplemente poner un TSqlQuery en el servidor con la consulta "SELECT * FROM MITABLA', ligar este query a un TDatasetProvider, luego en el cliente poner un TClientDataset y ligarlo al TDasetProvider, darle un Append al TClientDataset, poner los nuevos datos, luego darle un ApplyUpdates y ya terminé la tarea sin consumir ningún método explícito en el servidor.
En cambio podría tener en el servidor, un DataModule, un ServerDatamodule o incluso una simple Unit, con una clase que represente a un registro de dicha tabla, y tener un método público Insertar que reciba los parámetros, llame a una conexión y realice la inserción; y como es lógico el cliente debería consumir el método Insertar pasando los parámetros.
Esta segunda opción obviamente requiere de mucho más trabajo pero es mucho más escalable y más fácil de mantener, en este punto podrías echar mano de un ORM de terceros como TMSAurelius que es full compatible con DataSnap y hace un uso elegante de las características de las nuevas versiones de delphi como los genéricos, los atributos y los métodos anónimos.
En conclusión las reglas de negocios las puedes tener completamente independientes del tipo de servidor, del tipo de DB, incluso del tipo de aplicación (podría no ser DataSnap).
Si decides arrancar en firme podemos en cuanto disponga de un tiempo iniciar un minitutorial.
Un saludo.