Intégration d'entreprise de systèmes disparates

Question

Nous sommes sur le point d'entreprendre un effort d'intégration assez important pour détruire un grand nombre de bases de données Access et Sql Server et tout mettre en place dans un seul système d'entreprise cohérent. Il existe également un certain nombre d'autres systèmes (comptabilité, CRM, paie, MS Exchange) qui contiennent des données critiques que nous devons intégrer (utiliser pour la validation des données dans d'autres systèmes), créer des rapports et les exposer autrement. Il est probable que certains de ces systèmes vont changer au cours des prochaines années, nous devons donc isoler nos systèmes pour être prêts à changer.

Idéalement, nous serions en mesure d'exposer nos formes de manière cohérente sur le plus grand nombre possible de nos systèmes sans avoir à les développer de nouveau pour chaque système. Nous ciblons actuellement SharePoint (2007 et bientôt 2010), Office (2007 et bientôt 2010 - Word, Excel, PowerPoint et Outlook), Reporting Services, les applications console .Net, les applications Windows .Net, les extensions shell, et avec la possibilité d'exposer certaines fonctionnalités sur les appareils mobiles (BlackBerries actuellement, peut-être iPhones plus tard) et via notre site Web. Nous déplaçons le développement vers Visual Studio 2010 (à partir de 2005) avant la migration vers SharePoint 2010 et Office 2010. Étant donné que la majeure partie de notre développement est actuellement orientée vers le framework .Net (principalement en C#), il semble logique de s'en tenir à cela à moins qu'il y ait une raison impérieuse de changer de framework/plateforme pour certains aspects. Nous pensons à votre couche standard Database-> Data Integration Couche-> Business Objects Layer-> Web Services (ou REST) ​​Couche-> Application client et à notre propre application client avec WPF (ou quelque chose d'autre?) cela peut également être exposé dans les systèmes MS (SharePoint, Office, Windows). Donc, nous ne voulons pas beaucoup, juste tout :) Fondamentalement, nous devons nous isoler de la base de données et les changements de systèmes, créer une API qui peut être utilisée dans nos systèmes, puis rendre cette fonctionnalité disponible dans nos applications client.

Je suis très désireux d'obtenir des conseils de tous ceux qui ont des conseils sur la façon de réussir. Devrions-nous regarder la bibliothèque d'entreprise comme un endroit pour commencer ou rouler la nôtre? Est-ce que REST avec ASP.Net MVC2 est une meilleure solution que les services Web pour un système comme celui-ci? WPF fournira-t-il des formulaires de réutilisation ou y a-t-il quelque chose de mieux?

Answer 1

Je recommande une seule application composite pour votre application métier. Ensuite, il n'y a pas besoin de "réutilisation des formulaires", les vues sont toutes là et intégrées ensemble. Tous vos accès aux données peuvent passer par une seule couche réutilisable et toutes les applications tierces communiquent avec votre système via les techniques de SOA.

Le groupe Patterns and Practices de Microsoft fournit quelques frameworks pour le développement d'une seule application extensible, pluggable et modulaire qui peut être déployée via un mécanisme de déploiement unique. Si vous avez un contrôle complet sur la plate-forme de vos utilisateurs finaux (Windows), je recommande WPF en utilisant Prism et si ce n'est pas le cas, je recommande Silverlight en utilisant Prism. Si vous n'avez pas encore migré vers la technologie WPF/Silverlight, vous pouvez développer une bonne application composite Windows Forms avec les composants Unity de Prism ou SCSF, qui est beaucoup plus développé pour WinForms. (Remarque: WPF peut héberger des contrôles WinForms et WinForms peut héberger des contrôles WPF, vous pouvez donc créer une solution hybride avec des composants existants lorsque vous vous dirigez vers un système d'entreprise complet et cohérent.) Prenez garde que SCSF/CAB et Prism Vous devrez familiariser votre équipe avec les principes fondamentaux de l'OO et les motifs de conception. En ce qui concerne la solution mobile, je pense que vous pouvez développer des vues WPF pour Windows Mobile, ce qui vous permet de réutiliser l'application avec différentes vues sur les appareils mobiles.

WCF est sans aucun doute le meilleur framework SOA pour la communication inter-applications dans .NET.

Si vous avez un workflow, des chaînes d'approbation ou des besoins de routage de document, utilisez WF. Vous pouvez même intégrer des éditeurs de flux de travail dans l'application composite afin que les utilisateurs finaux puissent modifier et mettre à jour les flux de travail en fonction des besoins de l'entreprise, sans vous appeler.

Si vous n'utilisez pas déjà un ORM, alors je vous recommande nHibernate. Ne développez pas votre propre couche d'accès aux données pour l'intégration avec le SGBDR, c'est idiot; voir here. Regardez dans ClickOnce pour le déploiement de cette application; Le support intégré permet à votre application de détecter et d'installer automatiquement les mises à jour.