Architecture déconnectée ou connectée

Question

Une architecture déconnectée est-elle trop complexe pour le scénario suivant? Je serais reconnaissant si quelqu'un pouvait partager des opinions ou des expériences qu'ils pourraient avoir.

Il existe une application métier qui s'exécute à l'intérieur du réseau d'entreprise, à savoir une application de bureau et une base de données SQL Server. Certaines données sont exposées au grand public via une application Web. L'application Web est cependant déconnectée de la base de données principale - elle utilise essentiellement une réplique réduite. Nous utilisons T-SQL pour synchroniser les données entre les deux bases de données.

Le système devient de plus en plus coûteux à développer et à maintenir en raison de la couche de synchronisation. Je ne peux pas m'empêcher de penser que si l'application Web parlait à la base de données du bureau via les services Web ou WCF (suppression de la couche de synchronisation), les coûts diminueraient.

Answer 1

Je pense que aller de l'avant avec le service WCF serait une option rentable. Il serait plus facile à maintenir que la couche de synchronisation et le service WCF sont construits en gardant à l'esprit des problèmes comme celui-ci.

Answer 2

Dépend des volumes de données que vous gérez. Généralement, vous utiliseriez une base de données de traitement des transactions en ligne avec un entrepôt de données plus grand, où vous avez une grande quantité de données et la vitesse d'un db plus petit pour les données en temps réel et d'entrepôt pour les rapports et l'analyse des données hors ligne. En supposant que vous ne disposiez pas d'une grande quantité de données à gérer qui ralentirait le côté Web lors de l'interrogation/mise à jour, essayez de créer des vues équivalentes dans la base de données principale et d'interagir avec le site Web.

Answer 3

Jetez un coup d'oeil à Web Synchronization for Merge replication, une fonctionnalité introduite dans SQL Server 2005, et idéalement adapté à ce scénario car il utilise HTTPS.