Consejos sobre el paso a una arquitectura de múltiples niveles Delphi

Question

Tenemos una relativamente grande aplicación que está fuertemente ligado a Firebird (procedimientos almacenados, vistas, etc). Ahora estamos recibiendo una gran cantidad de solicitudes de apoyo a las bases de datos adicionales y también nos gustaría mover una gran cantidad de la funcionalidad desde el cliente al servidor.

Ahora que parece ser un buen momento para pasar a una (4), la arquitectura de 3 niveles. Ya hemos visto en DataSnap 2009 y RemObjects SDK / DataAbstract. Ambos parecen como si fuera a hacer el trabajo, pero ¿existen ventajas / desventajas hay que mirar hacia fuera? ¿Hay otros marcos que usted podría recomendar?

Cheers, 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 que tha RemObjects apoya)).

Esto podría hacer una reimplementación de una capa simple tarde (como si más adelante tiene que hacer una nueva versión de la aplicación cliente-en un navegador / java / Silverlight).

Answer 2

Puedo recomendar el uso de los componentes de middleware de KBM Components4Developers. Hay un poco de una curva de aprendizaje, pero son muy flexibles y se mantienen bien en condiciones de uso en condiciones del mundo real.

comentario de un usuario ( 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á que una gran cantidad de cambios en nuestra arquitectura de la aplicación, me recomendó ir con esto en el futuro, pero se puede lograr el soporte para múltiples bases de datos, con otros productos como

UniDAC de DevArt (Best componentes para 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 (fuente abierto).

usando uno de los componentes anteriores, se dará apoyo para la mayoría de las bases de datos principales, junto a ella no le hará Doig muchos cambios, y en algunos casos basta con sustituir los componentes de base de datos antiguos con los nuevos, y tal vez cambiar algunos de propiedades.

Sin embargo, el cambio de multi-niveles no sólo hará que sólo son compatibles con más bases de datos, pero va a separar la lógica de negocio de la capa de presentación, por lo tanto, usted puede tener más capas de presentación para su aplicación como interfaz web o dispositivos inteligentes.

Pero lo más importante en la arquitectura multi-Tercer, tendrá un sistema escalable al crecer más de lo que la base de datos que está utilizando puede manejar de conexión, junto a otros beneficios, como el uso de otros idiomas para escribir aplicaciones de 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 el middleware orientado a mensajes, entre lenguajes y la integración de aplicaciones multiplataforma se puede implementar mediante el peer-to-o el modelo de comunicación de publicación / suscripción. Los sistemas de mensajería están relacionadas de forma flexible, fiable y asíncrona. Por ejemplo, son componentes de la base en Java servidores de aplicaciones (tm) como JBoss.

Para pájaro de fuego, hace poco escribió un artículo en el blog en la sustitución de los eventos de base de datos Firebird, sus limitaciones y formas de reemplazar con soluciones basadas en el mensaje-corredor (que están disponibles como código abierto):

• base de datos Firebird y Eventos Mensaje -oriented Middleware (parte 1)
• Firebird base de datos de eventos y middleware orientado a mensajes (Parte 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).