Meilleures pratiques pour déplacer une grande application MS Access vers .Net?

Nous avons une application MS Access vraiment énorme développée initialement en interne pour nos besoins personnels qui a ensuite été transformée en logiciel commercial et vendue avec succès. Le logiciel est une sorte de "logiciel complet pour votre entreprise" et contient plusieurs modules, y compris le système de gestion de documents, la planification des ressources d'entreprise, la gestion des stocks, la gestion de la relation client, l'analyse des données, etc. Nous sommes assez satisfaits de la situation actuelle. fonctionnalité de l'application, mais afin de répondre aux demandes de nos clients, nous nous rendons compte que nous devons passer à quelque chose de nouveau.

Nous avons décidé de déplacer progressivement notre application vers .Net car nous pouvons nous en tenir à Visual Basic .Net: même s'il s'agit d'un nouveau langage pour la plupart des développeurs ici, nous avons une connaissance approfondie de VBA et plusieurs dizaines de petits projets implémentés dans VB6.

Nous avons déjà commencé à déplacer la fonctionnalité de couche de données de notre application vers MS SQL Server, afin que chaque manipulation et recherche de données soit effectuée directement sur le serveur.

Ce que nous recherchons, ce sont les meilleures pratiques pour déplacer progressivement notre interface graphique étendue (environ 500 à 600 formulaires différents, y compris des sous-formulaires, environ 200 rapports avec prise en charge multilingue, etc.). Suite à la récente demande de notre client potentiel d'implémenter le chiffrement asynchrone des données sur les documents dans DMS, nous serions également heureux de découpler complètement cette partie de MS Access et de l'implémenter dans .Net.

La question est de savoir comment intégrer de manière transparente l'application .Net au système MS Access existant, afin de pouvoir l'invoquer avec certains paramètres (droits d'utilisateur, etc.) et permettre l'échange de données entre cette application et l'application MS Access en cours d'exécution.

MODIFIER:

Nous avons essayé d'appliquer certaines pratiques du livre de Martin Fowler " Enterprise intergration patterns " pour réaliser une certaine intégration entre l'application MS Access et quelques petits utilitaires que nous avons mis en œuvre dans .Net pour divers besoins. Mais nous avons seulement réussi à utiliser le modèle de «base de données partagée» et nous n'étions pas vraiment satisfaits de notre solution.

Par exemple, nous avons implémenté un petit utilitaire fonctionnant en tant que service Windows qui télécharge automatiquement tous les messages du serveur de messagerie à l'aide d'une connexion POP3 et les stocke dans une table, tandis que toutes les pièces jointes sont stockées dans le système de fichiers.

Ce que nous avons principalement fait, c'est que nous avons utilisé ADO.NET pour accéder directement aux bases de données MS Access au format MDB et remplir la table avec des données traitées (comme les données sur les messages électroniques de l'exemple ci-dessus: nous avons des champs pour FROM, TO, CC, BCC, Sujet et corps).

Il n'y a absolument aucun problème à travailler avec le format de données MDB à partir de .Net , de plus, nous ne voulons pas rester avec MDB et migrer presque tout vers MS SQL Server 2008 - cela nous donne beaucoup plus de liberté concernant la gestion des données et l'évolutivité.

Le problème principal ici est que nous ne savons pas comment implémenter une sorte de "rappel" dans Access afin de pouvoir déclencher l'exécution de certains codes VBA lors de la mise à jour des données.

Nous avions de grands espoirs avec MS Access 2010 prenant en charge la mise à jour et l'insertion de déclencheurs pour les tables de données , mais il s'est avéré que nous ne pouvons utiliser que les macros MS Access pour ces déclencheurs et il n'y a aucun moyen d'exécuter du code VBA personnalisé dans le déclencheur.

Nous avons également essayé quelques solutions avec l' envoi de frappes directement à la fenêtre MS Access pour imiter certaines requêtes de données invoquées par l'utilisateur. Cela fonctionne, mais nous ne pensons pas que ce soit une solution viable qui puisse être utilisée en production.

Nous avons également examiné DDE pour MS Access, mais nous n'avons trouvé aucun bon exemple de solution implémentant les commandes DDE et les utilisant pour les données en mémoire et l'échange de commandes.

Ainsi, le principal problème est que MS Access et l'application .Net coexistent et interagissent.

EDIT2 :

J'ai oublié de mentionner ce que nous avons également implémenté la bibliothèque MSMQ dans VBA pour le passage des messages entre .Net et MS Access, le problème était à nouveau le manque de rappel ici: nous avons vraiment dû interroger la file d'attente pour les nouveaux messages et étant donné que VBA ne prend pas vraiment en charge multi-thread, ce n'était pas vraiment une bonne solution.

Ce sera un projet important et très impliqué. J'ai été responsable de la migration de bases de données Access vers .NET à plusieurs reprises, mais jamais à cette échelle. Je conviens qu'une approche progressive sera probablement la plus réaliste. Essayer de tout prendre d'un coup est un moyen simple d'échouer.

Comme dans les autres réponses, la première étape et la plus importante sera de tout déplacer vers SQL Server. En faisant cela, documentez la base de données si cela n'a pas déjà été fait et identifiez les zones de refactorisation si elles existent. Les bases de données d'accès qui se développent pour répondre aux besoins changeants ont souvent des modèles de données qui peuvent être améliorés lorsque vous regardez la vue d'ensemble.

Ensuite, identifiez les modules de l'application qui sont "autonomes". Comme il s'agit d'une base de données tout faire, il y aura probablement des modules qui sont presque complètement disjoints les uns des autres. Après avoir ces pièces disjointes, identifiez l'un des modules les plus petits qui a le plus à gagner à être mis à jour et prenez-le en premier.

Lors de la migration vers .NET, ne faites pas qu'une simple copie 1 à 1 de l'application. Rassemblez les commentaires des utilisateurs pour identifier les problèmes avec l'application actuelle. Vous voulez que votre première unité de migration soit un énorme succès pour gagner l'adhésion complète de tout le monde.

Après avoir terminé la première unité, regardez ce qui s'est passé en termes de défis, de difficultés, etc., et utilisez-le pour aller de l'avant.

Une chose que je déconseillerais fortement serait d'implémenter des modules fonctionnant partiellement (ex: "nous avons migré le CRM, mais les fonctionnalités X, Y, Z ne sont pas encore dans le nouveau système"). Cela rendra rapidement les utilisateurs frustrés d'avoir un système incomplet alors que l'ancien leur était "parfaitement bien". Ce type de développement peut fonctionner correctement pour d'autres domaines, mais pas dans les entreprises où les utilisateurs ne voient «rien de mal» avec l'ancien monolithe Access et ne comprennent pas les besoins de migration.

Voici une sorte de plan pour transformer votre application MS Access en une application VB.Net par mutation.

Ce n'est pas un plan général, le plan suivant dépend du projet que vous avez décrit.

Étape 1: migrer toutes les données vers SQL Server

N'utilisez pas ODBC pour la connexion Accès à SQL Server, utilisez plutôt un projet d'accès (ADP). Un projet Access est un fichier Access avec une extension .adp, il dispose de toutes les fonctionnalités Access (macros, formulaires, rapports, modules) mais la connexion se fait directement sur une base de données SQL Server au lieu d'un fichier MDB. Les fichiers ADP sont très compatibles avec les fichiers MDB. Ils semblent ne pas être pris en charge dans Access 2010, alors qu'en fait la fonctionnalité est masquée mais elle est très bien prise en charge. Comme MDE, les fichiers ADP peuvent être "compilés" en fichiers ADE.

La migration vers SQL Server coûtera peu de modifications dans la structure des données et le code, mais tout est assez facile à migrer. Et c'est un objectif final après tout.

Oubliez le déclenchement d'événements de base de données en code VBA ou VB.Net. Cela peut techniquement être fait à l'aide des procédures stockées étendues de SQL Server, mais c'est une très mauvaise astuce. Votre projet a une vie future, il est donc préférable de renforcer sa structure de données en évitant ce type de pont de déstructuration. En général, minimisez les déclencheurs de base de données, c'est intelligent mais assez difficile à maintenir.

Étape 2: uniformiser l'authentification

C'est une bonne chose que votre application ne soit pas basée sur la sécurité Access (fichier MDW).

Faites un plan pour l'authentification cible pour l'application VB.Net, puis définissez un moyen de migrer l'authentification Access vers cette cible afin d'avoir une authentification uniforme entre les deux applications.

Étant donné que l'authentification est transversale dans une architecture d'application, il sera plus facile de couper entre la version Access et la version VB.Net.

Étape 3: préparer une fonctionnalité de jeton afin de faire un pont entre Access et VB.Net

Vous avez dit que l'interface utilisateur d'accès devra ouvrir une interface utilisateur VB.Net avec des paramètres précis et également une authentification. Et vous devrez probablement faire de même dans l'autre sens.

Une bonne solution consiste à créer une petite fonctionnalité de jeton basée sur une table de jetons: les colonnes peuvent être un identifiant de jeton (entier), une clé de jeton (longue chaîne), une date de jeton et une liste de paramètres (longue chaîne ou texte). Chaque fois qu'Access doit ouvrir un écran VB.Net, puis enregistrer un jeton dans la base de données avec les paramètres, puis ouvrir votre application VB.Net avec uniquement l'ID de jeton et la clé de jeton. Le VB.Net s'ouvre, recherchez l'ID de jeton dans la base de données, vérifie la clé (cela s'applique en tant qu'authentification) et lit les paramètres. Ensuite, il s'ouvre sur le formulaire correspondant et fait ce qui est nécessaire. N'oubliez pas de donner une durée aux jetons et de nettoyer les anciens jetons.

Si vous devez rappeler de VB.Net à Access (vous le ferez probablement), je pense qu'il est possible d'activer du code VBA sur un fichier MDB Access ouvert, en utilisant OLE.

Étape 4: migrer l'interface utilisateur et les modules écran par écran, module par module

Maintenant, la grande préparation est terminée. Vous pouvez commencer à migrer l'interface utilisateur de Ms Access vers VB.Net.

Il n'y a pas de bons outils automatiques pour ce faire. VBA et .Net sont trop différents. Vous devez préparer votre travail pour une telle migration. Commencez avec un petit formulaire, comme la boîte «À propos», et passez de formulaires simples à des formulaires compliqués. Bien sûr, vous devrez regrouper et planifier certaines migrations, mais vous migrez progressivement vos écrans, rapports et bibliothèques de Ms Access vers VB.Net.

Je suis étonné que vous ayez fait tout cela avec Access. Il y a une question très importante que vous ne posez pas .NET Windows Forms ou .NET WPF. WPF a une courbe d'apprentissage plus abrupte mais à mon avis, il est plus puissant avec une meilleure interface utilisateur. Nous avons récemment converti notre application commerciale de Forms en WPF et nous obtenons déjà plus de ventes. Nous avons également ajouté de nouvelles fonctionnalités, mais l'interface utilisateur WPF est juste plus sexy. Examinez la conception de votre table et nettoyez-la - c'est le moment. Assurez-vous de déclarer tous vos FK. Dans Access, vous pouvez ajouter des éléments à la volée assez facilement à certains moments. S'il s'agit de votre première interface utilisateur WPF, créez des prototypes. Nous pourrions emballer davantage dans WPF que la nouvelle application a plus de fonctionnalités, moins d'écrans et moins de code. Vous passerez de la haine de XAML à son amour. Prenons une structure comme MVVM.

Étant donné que vous avez déjà une bonne compréhension du modèle d'objet Access, je pense que vous souhaitez utiliser Access Interop à partir de votre application .NET. Il devrait (plus ou moins) vous permettre d'automatiser le contrôle d'une application Access, sans l'opacité de DDE.

Je ne connais pas les connaissances approfondies de votre couche logique métier, mais vous pouvez également accéder à vos bases de données MS Access dans votre application .NET. S'il ne s'agit pas simplement de récupérer des données, vous pouvez implémenter une connexion TCP / IP entre vos programmes (applications VB6 et VB.NET). Veuillez consulter un article sur CodeProject .

Vous demandez une meilleure pratique sur la façon de faire la mauvaise chose. Il n'y en a pas. Les meilleures pratiques comprennent la façon de créer efficacement un système maintenable, de sorte que même si un bus tombe en panne et qu'une toute nouvelle équipe doive venir à froid, le développement et le support puissent continuer. Le système que vous décrivez va envoyer la plupart des développeurs courir pour les collines. Vous avez un produit construit avec une technologie obsolète et souhaitez vous interfacer avec la technologie d'aujourd'hui. Et vous voulez le faire sans vous attaquer à l'un des modèles d'anti que vous avez décrits pour le produit principal. Les développeurs qui sont prêts à s'y attaquer ne seraient probablement pas disposés à le faire avec les conditions que vous proposez.

Cependant, votre bus n'est pas tombé en panne, vous pouvez donc tirer parti de l'équipe existante qui comprend le système. La meilleure façon de se développer progressivement que j'ai trouvée est d'utiliser la méthodologie Agile. Il prend en charge un processus itératif qui répond rapidement aux exigences à haut risque et répond bien aux besoins de l'entreprise.

Nous avons décidé de déplacer progressivement notre application vers .Net

Souvent une erreur. La meilleure pratique consiste à ne pas essayer "progressivement".

même s'il s'agit d'un nouveau langage pour la plupart des développeurs ici, nous avons une connaissance approfondie de VBA et plusieurs dizaines de petits projets implémentés dans VB6.

Pas une très bonne base pour une décision. Si vous voulez apprendre une nouvelle langue, n'apprenez pas le VB. Apprenez C # ou quelque chose de mieux encore comme Java.

"un nouveau langage pour la plupart des développeurs ici, nous avons une connaissance approfondie de VBA" est une phrase de code courante pour "nous avons un gourou VBA que nous ne voulons pas irriter". C'est peut-être aussi quelque chose de mauvais.

Ce que nous recherchons, ce sont les meilleures pratiques pour déplacer progressivement notre interface graphique étendue

Les meilleures pratiques n'impliquent pas "Graduel". Ils impliquent "Jeter Entièrement".

Les migrations progressives que j'ai vues se sont interrompues parce que c'est si difficile.

Tu ferais mieux de faire ça.

1. Préservez l'atout le plus précieux . Les données. Déplacez toutes les données vers SQL Server. Tout. Réécrivez tous les MS-Access pour utiliser des connexions ODBC à SQL Server. Maintenant.

2. Renvoyez toute personne qui crée des tables ou des données temporaires ou quoi que ce soit dans MS-Access. Toutes les données doivent vivre dans une base de données en dehors de MS-Access. Les données dans MS-Access sont à l'origine des problèmes, alors arrêtez-vous maintenant et assurez-vous que tout le monde est d'accord. S'ils ne sont pas d'accord, trouvez-leur un nouvel emploi qui n'implique pas de piratage dans MS-Access pendant que vous essayez de vous débarrasser de MS-Access.

3. Trouvez un cadre de reporting qui générera automatiquement des rapports proches de ce que vous avez actuellement. Pas de programmation. Donnez-lui simplement une table ou une vue et cognez! c'est fait.

4. Énumérer les 500 rapports. Les partitionner en rapports faciles à créer avec l'outil et en rapports plus difficiles. Donner la priorité aux plus difficiles en "Doit avoir", "Devrait avoir", Pourrait avoir "et" Ne le fera que plus tard ". Remplacez les rapports automatisés et les rapports indispensables cet outil de rapport complètement en dehors de MS-Access.

   D'après mon expérience, une vue de base de données est souvent réutilisée dans une vingtaine de rapports. À partir de cela, je suppose que vous avez 25 vues pertinentes à partir desquelles les 500 rapports sont dérivés. Tout outil capable d'automatiser la production de rapports doit gérer la plupart de vos rapports à partir d'un petit ensemble de vues SQL bien conçues. Quelques rapports seront trop complexes ou difficiles pour un outil automatisé.

5. Trouvez un cadre de développement qui génère automatiquement les transactions CRUD.

6. Partitionnez vos 200 formulaires en formulaires CRUD (qui peuvent être créés automatiquement) et non CRUD. Parmi les non-CRUD, priorisez l'utilisation des règles MoSCoW (Must, Should, Can't, Won't).

   Souvent, 60 à 80% des formulaires de demande sont des formulaires CRUD simples et automatisés. 20 à 40% sont plus complexes et nécessitent une programmation plus compétente. Sur cette base, vous disposez de 120 à 160 formulaires CRUD que vous n'avez pas besoin de réécrire, il suffit d'automatiser. Vous avez 40 à 80 transactions sérieusement complexes.

7. Créez les formulaires CRUD et les formulaires Must-have non-CRUD.

8. Évaluez les lacunes. Redéfinissez les priorités et commencez à travailler sur les parties les plus importantes de la liste des «indispensables».

Il est probablement plus facile de supprimer complètement Access. Évitez le gradualisme.

Vous allez finir par dépenser tout l'argent.

Vous pouvez aussi bien le budget et le dépenser maintenant.

Essayer de le faire progressivement peut en fait être plus coûteux en raison de la complexité de la gestion de la coexistence.