database - Asesoramiento para pasar a una arquitectura Delphi de varios niveles

architecture delphi-2009 (5)

Tenemos una aplicación relativamente grande que está estrechamente relacionada con Firebird (procedimientos almacenados, vistas, etc.). Ahora recibimos muchas solicitudes para admitir bases de datos adicionales y también nos gustaría trasladar gran parte de la funcionalidad del cliente al servidor.

Ahora parece un buen momento para pasar a una arquitectura de 3 (4) niveles. Ya hemos analizado DataSnap 2009 y RemObjects SDK / DataAbstract. Ambos parecen que harían el trabajo, pero ¿hay ventajas / desventajas que debemos tener en cuenta? ¿Hay algún otro marco que puedas recomendar?

Saludos, Paul

Cambiar su aplicación a Multi-Tiers con un nuevo framework (RM, DS, kbmMW, o lo que sea), hará muchos cambios en la arquitectura de nuestra aplicación, recomendé que vaya con esto en el futuro, pero puede lograr el soporte para múltiples base de datos, con otros productos como

UniDac de DevArt (los mejores componentes para la base de datos con conexión directa). AnyDac (de la misma compañía que ofrece RemObjects. SqlDirect (tiene soporte para 9 MajorDB y también ODBC). ZeosDB (fuente abierta).

utilizar uno de los componentes anteriores le dará soporte para la mayoría de las principales bases de datos, además de que no le hará realizar muchos cambios, y en algunos casos simplemente reemplazará los componentes viejos de la base de datos por los nuevos y tal vez cambie algunas de las propiedades.

Sin embargo, cambiar a varios niveles no solo le permitirá admitir más bases de datos, sino que también separará su lógica empresarial de la capa de presentación, por lo tanto, puede tener más capas de presentación para su aplicación, como la interfaz web o los dispositivos inteligentes.

Pero lo más importante en la arquitectura Multi-Tiers, tendrá un sistema escalable para que crezca más de lo que la base de datos que está utilizando puede manejar de conexión, además de otros beneficios, como usar otros idiomas para escribir aplicaciones cliente.

En el proceso de pasar a una aplicación de varios niveles, podría considerar usar un protocolo de transporte entre las capas, que es independiente del lenguaje / tecnología (como los servicios web, (creo que los proyectos de remodelación lo admiten)).

Esto podría hacer que una reimplementación de una capa sea más simple más tarde (como si luego tuviera que crear otra versión de la aplicación cliente en un navegador / java / silverlight).

Puedo recomendar el uso de los componentes de KBM Middleware de Components4Developers. Existe una pequeña curva de aprendizaje, pero son muy flexibles y se mantienen bajo uso en condiciones reales.

Comentario de un usuario ( http://www.components4programmers.com/usercomments/commentfromapowerusertoaquestion.htm )

También puede investigar Midware http://www.overbyte.be/frame_index.html

Para la arquitectura de varios niveles, también recomiendo ver el middleware orientado a mensajes.

Con el middleware orientado a mensajes, la integración de aplicaciones entre idiomas y multiplataforma se puede implementar utilizando el modelo de comunicación punto a punto o de publicación / suscripción. Los sistemas de mensajería están flojos, asíncronos y confiables. Por ejemplo, son componentes principales en servidores de aplicaciones Java (tm) como JBoss.

Para Firebird, recientemente escribí un artículo de blog sobre cómo reemplazar los eventos de la base de datos Firebird, sus limitaciones y formas de reemplazarlos con soluciones basadas en Message Broker (que están disponibles como código abierto):

(descargo de responsabilidad: soy un desarrollador de bibliotecas de clientes de Delphi y Free Pascal para corredores de mensajes de código abierto).