Consejos para pasar a una arquitectura Delphi de varios niveles

Question

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

Answer 1

En el proceso de pasar a una aplicación de varios niveles se podría considerar el uso de un protocolo de transporte entre las capas, que es el lenguaje/independiente de la tecnología (como servicios web, (creo tha RemObjects apoyos que))

Esto podría hacer una reimplementación de una capa 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).

Answer 2

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.

Comment from a user (http://www.components4programmers.com/usercomments/commentfromapowerusertoaquestion.htm)

Answer 3

Cambiar su aplicación a Multi-Niveles con el nuevo marco (RM, DS, kbmMW, o lo que sea), hará una gran cantidad de cambios en nuestra arquitectura de la aplicación, que recomienda ir con este en el futuro, pero puede lograr el soporte para múltiples bases de datos, con otros productos como

UniDac de DevArt (Mejores componentes para la base de datos con conexión directa). AnyDac (de la misma organización que ofrecen RemObjects. SqlDirect (Tiene soporte para 9 MajorDB y ODBC). ZeosDB (código abierto).

usando uno de los componentes anteriores, le dará apoyo para la mayoría de las bases de datos principales, al lado 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 lo hará solo admite más bases de datos, pero 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 web. interfaz o dispositivos inteligentes.

Pero lo más importante en la arquitectura Multi-Tiers, tendrá un sistema escalable que crecerá 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.

Answer 4

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

Answer 5

Para la arquitectura de varios niveles También recomiendo de revisar el middleware orientado a mensajes.

Con middleware orientado a mensajes, la integración de aplicaciones entre idiomas y multiplataforma se puede implementar utilizando el modelo de comunicación entre pares 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, hace poco escribió un artículo en el blog en la sustitución de los eventos Firebird base de datos, sus limitaciones y formas de reemplazar con soluciones basadas en el mensaje-corredor (que están disponibles como código abierto):

• Firebird Database Events and Message-oriented Middleware (part 1)
• Firebird Database Events and Message-oriented Middleware (part 2)

(exención de responsabilidad: soy un desarrollador de bibliotecas de cliente de Delphi y Free Pascal para intermediarios de mensajes de código abierto).