Как форсировать порядок выполнения Установщика

Question

Я строю новое решение .NET, где Касл выполняет мой DI.

Сейчас на стадии, где я хотел бы контролировать порядок, в котором работают мои установщики. Я создал отдельные классы, которые реализуют IWindsorInstaller для обработки моих основных типов - например, IRepository, IMapper и IService.

Я вижу, что в этом классе предлагается реализовать мою собственную InstallerFactory (предполагаю, что я просто переопределил Select).

Тогда используйте эту новую фабрику в моем звонке:

FromAssembly.InDirectory(new AssemblyFilter("bin loca­tion")); 

Мой вопрос - при переопределении метода сохранения - каков наилучший способ навязать порядок моим установщикам.

Answer 1

Я знаю, что это уже решено, но я не смог найти ни одного примера о том, как на самом деле реализовать InstallerFactory, так что вот решение, если кто-нибудь ищет его.

Как использовать:

[InstallerPriority(0)]
    public class ImportantInstallerToRunFirst : IWindsorInstaller
    {
        public void Install(IWindsorContainer container, Castle.MicroKernel.SubSystems.Configuration.IConfigurationStore store)
        {
            // do registrations
        }
    }

Просто добавьте атрибут InstallerPriority с приоритетом для ваших классов, чувствительных к порядку установки.Установщики будут отсортированы по возрастанию.Установщики без приоритета по умолчанию будут иметь значение 100.

Как реализовать:

public class WindsorBootstrap : InstallerFactory
    {

        public override IEnumerable<Type> Select(IEnumerable<Type> installerTypes)
        {
            var retval =  installerTypes.OrderBy(x => this.GetPriority(x));
            return retval;
        }

        private int GetPriority(Type type)
        {
            var attribute = type.GetCustomAttributes(typeof(InstallerPriorityAttribute), false).FirstOrDefault() as InstallerPriorityAttribute;
            return attribute != null ? attribute.Priority : InstallerPriorityAttribute.DefaultPriority;
        }

    }


[AttributeUsage(AttributeTargets.Class)]
    public sealed class InstallerPriorityAttribute : Attribute
    {
        public const int DefaultPriority = 100;

        public int Priority { get; private set; }
        public InstallerPriorityAttribute(int priority)
        {
            this.Priority = priority;
        }
    }

При запуске приложения global.asax и т. Д .:

container.Install(FromAssembly.This(new WindsorBootstrap()));

Answer 2

Вы можете вызывать ваши установщики в том порядке, в котором они должны быть созданы в Global.asax.cs или, например, в классе Bootstrapper, который вызывается из Global.asax.cs.

        IWindsorContainer container = new WindsorContainer()
            .Install(                    
                new LoggerInstaller()           // No dependencies
                , new PersistenceInstaller()    // --""--
                , new RepositoriesInstaller()   // Depends on Persistence
                , new ServicesInstaller()       // Depends on Repositories
                , new ControllersInstaller()    // Depends on Services
            );

Онисоздается в этом порядке, и вы можете добавить точку останова после и проверить контейнер на "Potentially misconfigured components".

Если они есть, проверьте их Status -> details, если нет, то это правильный порядок.

Это решение быстрое и простое, в документации упоминается использованиеКласс InstallerFactory для более жесткого контроля над вашими установщиками, так что если у вас есть куча установщиков, другое решение может подойти лучше.(Использование кода в качестве соглашения не требует тонны установщиков?)

http://docs.castleproject.org/Windsor.Installers.ashx#codeInstallerFactorycode_class_4

Answer 3

В итоге мне пришлось использовать InstallerFactory и реализовать правила заказа, как было предложено ранее, вернув IEnumerable<Type> с моим конкретным заказом