Méthode recommandée pour remplacer l'assemblage du référentiel d'une application

Question

J'ai une application qui contient un assemblage de référentiel. Lorsque l'application est initialement installée, le référentiel est très simple: un magasin de fichiers JSON local. Mais je veux donner à mes utilisateurs finaux la possibilité d'utiliser un magasin de référentiel différent (SQL, Oracle, etc.).

Serait-ce aussi simple que de remplacer la DLL du référentiel d'origine dans le répertoire de l'application par la nouvelle DLL du référentiel? Si oui, l'utilisateur copierait-il simplement la nouvelle DLL du référentiel dans le répertoire de l'application, en écrasant la DLL d'origine? Existe-t-il une meilleure façon de le faire?

Notez que j'ai également un autre assembly dans l'application qui contient toutes les interfaces utilisées par l'application (est-ce une bonne pratique?). L'application vérifie que l'assembly de référentiel implémente toutes les interfaces requises. Je crois que je ne veux pas d'architecture/framework de plug-in. Je ne veux pas la possibilité d'en choisir une parmi un ensemble d'assemblages de référentiels chargés. Mais je vais écouter tout argument favorisant une stratégie de plug-in pour mon application.

Answer 1

Il existe plusieurs approches à ce sujet et de la question, je ne suis pas sûr lequel est le mieux adapté à vos besoins.

1. Si vous avez seulement besoin de choisir un comportement entre plusieurs implémentations situées dans DLL qui peuvent être chargés lorsque le démarrage de l'application, vous pouvez référencer ces statiquement. Au démarrage, vous pouvez parcourir l'AppDomain pour les assemblys chargés (vérifier la méthode AppDomain.GetAssemblies()) et les classes dans l'assembly et créer un dictionnaire des comportements disponibles. Ce dictionnaire peut ensuite être utilisé pour basculer entre les comportements. Si vous avez vraiment besoin que l'utilisateur gère les fichiers DLL lors de l'exécution, vérifiez les méthodes AppDomain.Load(). Cela permet le chargement dynamique d'un nouvel assemblage dans l'AppDomain actuel. Les classes de ces assemblys peuvent être converties en interfaces communes correspondantes pour être réellement appelées. Cependant, notez que le chargement d'un assemblage est facile mais le déchargement (si vous avez besoin de le faire) n'est PAS. Par conséquent, si vous devez charger ET décharger les assemblages de façon dynamique, ceux-ci doivent être gérés dans une méthode AppDomain différente (vérifier la méthode AppDomain.Unload()). De plus, les appels de méthode entre AppDomains ne peuvent pas être effectués directement, ils ont besoin de marshaling qui ajoute à la complexité du code.

Voici un bref résumé de ces solutions, il y a des articles détaillant chacun d'eux ...