В настоящее время я работаю над большим проектом, в котором есть библиотека DLL (назовем ее Common.DLL), которая часто обновляется, чтобы содержать новые классы, требующие регистрации через Unity для DI. Существует около 3 других приложений (веб-сайт, служба WCF и т. Д.), Которые ссылаются на эту DLL и имеют собственный файл конфигурации Unity, который, если новый класс создается в Common, все необходимо обновлять для регистрации этого нового типа.

Очевидно, управлять этим может быть непросто, и я наследую этот проект, поэтому я думаю о том, как упростить этот процесс. Следует отметить, что Common.DLL, безусловно, может быть помещена в пакет Nuget и распространена таким образом.

Я более или менее вижу, знает ли кто-нибудь хороший способ, где я обновляю Common.DLL или Common NuGet пакет с новым классом, а другие приложения обновляют свои регистрации, когда Common.DLL, на которые они ссылаются, изменяется или когда обновляется пакет. Любая обратная связь будет оценена. Спасибо!

0
forevermetal02 19 Июл 2017 в 23:29
Нужно ли в каждом проекте регистрировать типы Common.dll по-разному, или регистрации для разных проектов согласованы?
 – 
Randy supports Monica
20 Июл 2017 в 08:28
Последовательно, скажем, вы добавляете новый класс в Common, и вам нужно добавить регистрацию для этого класса. Это легко сделать, просто это нужно сделать несколько раз для каждого приложения, ссылающегося на него.
 – 
forevermetal02
20 Июл 2017 в 14:24

1 ответ

Лучший ответ

Поскольку вы упомянули, что классы в Common регистрируются одинаково для каждого приложения, я бы создал программную регистрацию для всех классов в Common. Unity позволяет сочетать программную и декларативную настройку. Таким образом, компоненты Common.dll могут быть зарегистрированы программно, в то время как регистрация конкретных приложений (которая может измениться) может быть выполнена с использованием конфигурации XML.

Я бы возложил бремя создания регистраций на разработчиков Common.dll, поскольку они будут знать, как должны регистрироваться классы, и их нужно будет делать только один раз (а не для каждого приложения). Когда будет обновление, все приложения просто сохранят изменения регистрации без изменения кода.

Вероятно, вы не хотите, чтобы Common.dll напрямую зависел от Unity, поэтому вы можете создать отдельную сборку для регистраций, таких как Common.Ioc.Unity.dll, и предоставить там метод для начальной загрузки регистраций Common.dll. например

public class RegistrationManager : IRegistrationManager
{
    private IUnityContainer container;
    public RegistrationManager(IUnityContainer container)
    {
        this.container = container;
    }

    public void RegisterCommon()
    {
        this.container.RegisterType<Common.Logger>(new ContainerControlledLifetimeManager());
    }
}

Вы даже можете предоставить разные варианты регистрации для поддержки разных контейнеров (при желании).

Обратной стороной является то, что это небольшая сборка, на которую также должно ссылаться приложение. Если существует много сборок, похожих на Common.dll, возможно, имеет смысл подумать о размещении всех общих регистраций в одной сборке.

Другой (стилистический) вариант вышеизложенного - реализация регистрации с использованием расширения контейнера. Например:

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

Тогда в приложении вы можете зарегистрироваться, используя:

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();
1
Randy supports Monica 20 Июл 2017 в 21:57