2017-07-19 1 views
0

Actuellement, je travaille sur un grand projet où il y a une DLL (appelons-le common.dll) qui est fréquemment mis à jour pour contenir de nouvelles classes qui nécessitent une inscription par l'unité pour DI. Il existe environ 3 autres applications (site Web, service WCF, etc.) qui font référence à cette DLL et possèdent leur propre fichier de configuration Unity. Si une nouvelle classe est créée dans Common, toutes les mises à jour nécessaires pour enregistrer ce nouveau type.enregistrements Unity Gestion pour les applications .NET faisant référence à une bibliothèque commune

De toute évidence, cela peut être une douleur à gérer et je héritant ce projet donc je pense à des façons de rendre ce processus plus facile. Il convient de noter que Common.DLL pourrait certainement être placé dans un paquet Nuget et distribué de cette façon. Je vois plus ou moins si quelqu'un connaît un bon moyen de mettre à jour le paquet Common.DLL ou Common NuGet avec une nouvelle classe et les autres applications mettent à jour leurs enregistrements quand Common.DLL ils référencent des changements ou quand le le paquet est mis à jour. Tout commentaire serait apprécié. Merci!

+0

Est-ce que chaque projet doit enregistrer les types common.dll d'une manière différente ou sont les enregistrements cohérents entre les différents projets? –

+0

Cohérent, disons que vous ajoutez une nouvelle classe à Common et que vous devez ajouter un enregistrement pour cette classe. C'est facile à faire, c'est juste qu'il faut le faire plusieurs fois pour chaque application en le référençant. – forevermetal02

Répondre

1

Puisque vous mentionnez que les classes en commun sont enregistrés de la même manière pour chaque application, je créerais l'enregistrement programmatique pour toutes les classes en commun. Unity permet le mélange programmatique avec la configuration déclarative. Ainsi, les composants Common.dll peuvent être enregistrés par programmation alors que les enregistrements spécifiques aux applications (qui peuvent changer) peuvent être effectués en utilisant la configuration XML.

Je placerais le fardeau de créer les inscriptions sur les développeurs de Common.dll puisqu'ils sauront comment les classes devraient être enregistrées et devront seulement être faites une fois (et pas pour chaque application). Quand il y a une mise à jour, toutes les applications vont simplement récupérer les changements d'enregistrement sans changer de code.

Vous ne voulez probablement pas que Common.dll dépende directement de Unity, vous pouvez donc créer un assembly séparé pour les enregistrements tels que Common.Ioc.Unity.dll et fournir une méthode pour les enregistrements Common.dll bootstrap. par exemple. Vous pouvez même fournir différents types d'enregistrement pour prendre en charge différents conteneurs (si vous le souhaitez).

L'inconvénient est que c'est un petit ensemble qui devra également être référencé par l'application. S'il existe plusieurs assemblys similaires à Common.dll, il peut être judicieux de penser à placer tous les enregistrements partagés dans un assembly.

Une autre variante (stylistique) de ce qui précède consiste à mettre en oeuvre les enregistrements en utilisant une extension de conteneur. Par exemple:

public class CommonContainerExtension : UnityContainerExtension 
{ 
    protected override void Initialize() 
    { 
     Container.RegisterType<Common.Logger>(new ContainerControlledLifetimeManager()); 
    } 
} 

Ensuite, dans l'application, vous pouvez vous inscrire à l'aide:

var container = new UnityContainer(); 

// Register Common.dll using container extension or RegistrationManager 
container.AddNewExtension<CommonContainerExtension>(); 

// Register XML configuration for application 
// Application can even overwrite Common.dll registrations from above if required 
container.LoadConfiguration();