Conception d'applications .NET avec plusieurs bases de données métier

Question

Les données de base de l'entreprise sont conservées et gérées dans des applications métiers distinctes, tierces et métier: Finance, Transport Management. Les clients sont créés dans l'application Finance (SQL Server), les informations de remise sont conservées dans l'application Gestion des transports (Oracle). La communication entre les deux est point-à-point.

Nous avons besoin de construire une nouvelle application (bien mettre à jour l'ancien, mais essentiellement à partir de zéro) pour traiter les réclamations des clients pour les livraisons endommagées ou courtes. Les réclamations, les données client et de livraison sont actuellement saisies manuellement dans MS Access. Cela sera migré vers une base de données SQL Server. La plate-forme de développement d'applications est VS2008 (C#). Je souhaite éviter d'avoir toutes les données client et de livraison dans la base de données de réclamations, puisque nous en détenons déjà ailleurs, donc je prévois de produire des flux basés sur WCF à partir des systèmes LOB (et éventuellement des réclamations db) qui peuvent ensuite être utilisé comme sources de données pour l'application de réclamation client. Il y aura une saisie de données spécifique à la réclamation, mais les données client et de livraison principales n'auront pas besoin d'être mises à jour dans les applications métier.

Jusqu'à présent, je pense à

base de données

-> ORM -> WCF \
base de données -> ORM -> WCF     ---> BLL -> UI
base de données -> ORM -> WCF/

mais il se sent mal car je vais créer des flux de service distincts pour les clients, les livraisons et les réclamations (services orientés objet?). Ce que je ne sais pas aussi, c'est comment et où je rejoins et travaillons à travers les sources de données dans l'application pour produire, disons, un rapport montrant les réclamations contre les livraisons par client (ie où j'écrirais traditionnellement une requête ou une vue ceci à partir de plusieurs tables dans une DB).

Suis-je sur la bonne voie ou je manque la grande image ici - devrais-je simplement exécuter des extraits réguliers dans une réclamation db et travailler avec l'architecture n-tier/n-layer traditionnelle?

Answer 1

Je ne pense pas que votre design soit trop loin de ce qu'il devrait être.

Si vous avez des applications qui accèdent aux données financières via le service WCF ou le service de transport, il est logique de les construire. Ils ont aussi un sens à construire parce que chacun de ces services vient soutenir ce dont il a besoin de savoir (lié au principe de responsabilité unique).

Lorsque l'application de l'interface utilisateur ne vous convient pas, appelez 3 services distincts pour effectuer le travail. Dans de telles situations, nous avons souvent construit un service d'encapsulation qui appelle le service approprié. Ce qui signifie que votre application d'interface utilisateur fait référence à un service WCF et que ce service appelle ensuite le service Finance ou le service de transport ou le service Claims. Inconvénient - chaque appel aboutit à plusieurs appels ... oui. Toutefois, cela élimine la logique de votre application d'interface utilisateur et vous permet de manipuler ou de combiner les données provenant des autres services ou d'ajouter une autre logique métier adaptée à l'application.Vous bénéficiez également du service Finance qui prend toujours en charge les applications de gestion des finances sans que les besoins de votre application d'interface utilisateur n'entravent le bon fonctionnement du code.

Je suis sûr qu'il existe différents chemins de solution pour cela. C'est exactement ce que nous avons fait dans quelques applications.

EDIT (répondre à votre question de suivi a pris trop de place pour faire un commentaire).

Si les données que vous pouvez obtenir à partir du service de transport est suffisant pour répondre à la question qui est posée en disant "getCustomerDelieveries" alors non, je ne le diviserais pas à un autre service de wrapper. Si vous avez besoin de plus de données, alors quelles autres applications bénéficieraient de ce service en fournissant plus d'informations sur les clients? Ces applications dépendent-elles uniquement du service de transport? C'est l'un de ceux où la réponse doit «sentir» juste pour vous, puisque vous en savez le plus sur vos systèmes. Peut-être avez-vous besoin d'enfreindre la règle SRP et de demander à votre service de transport d'obtenir plus d'informations sur les clients auprès de la banque ou du service financier. Ou, si les applications qui dépendent du service de transport ont régulièrement besoin de plus de données client, il pourrait être envisagé d'étendre la table client dans la base de données Transport.

Aucune règle, principe ou philosophie ne doit être appliqué de façon si rigide que vous ne pouvez pas le casser si cela a plus de sens pour votre application. Ça va être un équilibre et il n'y a pas de bonne ou de mauvaise réponse, juste ce qui fonctionne mieux pour cette situation.

Vous avez commencé ce post en parlant d'une nouvelle application d'interface utilisateur qui prend en charge la partie Revendications de votre entreprise et qui nécessitait à la fois des données sur les finances et le transport (ainsi que les siennes). C'est un candidat parfait pour appeler un service d'emballage. Il a besoin de données provenant de trois sources de données distinctes et distinctes. Votre service de transport a des informations client limitées qui fonctionnent bien pour certaines applications mais peut-être moins bien pour d'autres. Si vous écrivez un service d'encapsulation qui reflète votre service de transport à 100% et fournit en outre un peu plus de données client, qu'avez-vous gagné? Plus de données pour les applications qui le consomment mais également plus de maintenance pour vous chaque fois que vous ajoutez des fonctionnalités au service de transport. Quelle autre valeur pourrait fournir cet emballage?

Dans ce cas, selon moi, le fait que le service de transport obtienne plus de données clients du service des finances est «meilleur». Votre db de transport a quelques données mais pas assez. C'est presque comme si le service de transport avait besoin de compenser ce manque de données en répondant aux besoins de données lui-même.

Answer 2

Lors de la génération de rapports, il est généralement tolérable de ne pas fournir les données les plus à jour. Il peut donc être judicieux de dédier une base de données distincte comme source pour les requêtes de création de rapports. Vos bases de données maîtresses recevront des mises à jour de l'interface utilisateur (en tirant parti des transactions et de la détection des conflits), puis répliqueront les données dans la base de données de reporting. Ce motif architectural est appelé CQS (Command Query Separation), lisez ceci great article par Udi Dahan.

Answer 3

Je devrais utiliser un service d'orchestration avec WWF (ou un autre outil d'orchestration).

J'aime ce point de vue:

DAL, BLL, SIL -> WCf1 DAL, BLL, SIL -> WCF2

wcf1 et wcf2 sont reliés par un service d'orchestration sur eux. De cette façon, les services restent autonomes et découplés, et vous pouvez les réutiliser dans d'autres orchestrations.