Conseils sur le déplacement à un multi niveaux l'architecture Delphi

Question

Nous avons une application relativement importante qui est fortement liée à Firebird (procédures stockées, vues, etc.). Nous obtenons maintenant un grand nombre de demandes de soutien des bases de données supplémentaires et nous aimerions également déplacer une grande partie des fonctionnalités du client vers le serveur.

semble maintenant comme un bon moment pour passer à une architecture de niveau 3 (4). Nous avons déjà regardé DataSnap 2009 et RemObjects SDK / DataAbstract. Les deux semblent comme ils le feraient le travail, mais sont-il des avantages / inconvénients que nous devrions surveiller? Y at-il d'autres cadres que vous pourriez recommander?

Cordialement, Paul

Answer 1

Dans le processus de passer à une application multiniveau, vous pouvez envisager d'utiliser un protocole de transport entre les couches, qui est indépendante langue / technologie (comme webservices, (je pense tha RemObjects soutient que)).

Cela pourrait faire une ré-implémentation d'une couche plus simple plus tard (comme si vous avez plus tard pour faire une autre version de l'application client dans un navigateur / java / silverlight).

Answer 2

Je recommande d'utiliser les composants Middleware KBM de Components4Developers. Il y a un peu d'une courbe d'apprentissage, mais ils sont très flexibles et bien résister en utilisation dans des conditions réelles.

commentaire d'un utilisateur ( http://www.components4programmers.com/usercomments/commentfromapowerusertoaquestion.htm )

Answer 3

Changer votre application multi-tiers avec le nouveau cadre (RM, DS, kbmMW, ou ce que jamais), fera beaucoup de changements dans notre architecture d'application, je recommande d'aller dans cet avenir, mais vous pouvez obtenir le soutien à base de données multi, avec d'autres produits tels que

UniDAC de DevArt (meilleurs composants pour la base de données avec connexion directe). AnyDac (de la même société qui offrent RemObjects. SQLDirect (a un support pour 9 MajorDB et aussi ODBC). ZeosDB (open source).

en utilisant l'un des éléments ci-dessus, vous donner un soutien pour la plupart des grandes bases de données, à côté ne vous fera pas Doig beaucoup de changements, et dans certains cas, il suffit de remplacer les composants de base de données anciens avec les nouveaux, et peut-être changer quelques-uns des propriétés.

Cependant, le passage à multi-niveaux, non seulement vous faire soutenir que plusieurs bases de données, mais il séparera votre logique métier de la couche de présentation, vous pouvez donc avoir plusieurs couches de présentation pour votre application comme interface Web ou des appareils intelligents.

Mais le plus important dans l'architecture multi-tiers, vous aurez un système évolutif GROW plus que ce que la base de données que vous utilisez peut gérer la connexion, à côté d'autres avantages, comme l'utilisation d'autres langues pour écrire des applications client.

Answer 4

Vous pouvez également enquêter sur Midware http://www.overbyte.be/frame_index.html

Answer 5

Pour l'architecture à plusieurs niveaux, je vous recommande également de vérifier middleware orienté message.

Avec middleware orienté message, interlangage et l'intégration des applications multi-plateforme peut être mis en œuvre en utilisant le peer-to-peer ou le modèle de communication publish / subscribe. Les systèmes de messagerie sont faiblement couplés, asynchrone et fiable. Par exemple, ils sont des composants essentiels de serveurs d'applications Java (tm) telles que JBoss.

Pour Oiseau de feu, j'ai écrit récemment un article de blog sur le remplacement des événements de base de données Firebird, leurs limites et les moyens de les remplacer par des solutions à base de messages courtier (qui sont disponibles en open source):

• Événements Base de données Firebird et un message à orientation Middleware (partie 1)
• Firebird événements Base de données et Middleware orientés messages (Partie 2)

(disclaimer: Je suis un développeur de Delphi et gratuit bibliothèques clientes Pascal pour les courtiers de message open source).