Определите порядок инициализации классов WebActivator.PreApplicationStartMethod

Question

У меня есть несколько украшенных классов WebActivator.PreApplicationStartMethod.

Один для Ninject, другой класс для AwesomeMVC, а третий для планировщика фоновых задач.

Проблема в том, что класс планировщика должен использовать преимущества зависимостей, которые разрешаются контейнером IoC.

Мои вопросы:

1. Могу ли я иметь несколько классов WebActivator.PreApplicationStartMethod?
2. Могу ли я определить порядок, в котором они инициализируются, чтобы IoC, будучи наиболее важным, был на первом месте?
3. Могут ли экземпляры статического класса WebActivator.PreApplicationStartMethod полагаться на контейнер IoC для разрешения зависимостей, определенных конструктором?

Answer 1

Да, у вас может быть столько классов, сколько вам нужно, с атрибутом сборки WebActivator.PreApplicationStartMethod, указывающим на них.Многие пакеты NuGet используют эту технику, чтобы позволить им загружаться в ваше приложение без редактирования Global.asax.

Вы также можете определить порядок.Вы можете передать именованный параметр, Order в вызове PreApplicationStartMethod.Каркас WebActivator будет гарантировать, что методы вызываются в указанном порядке.Например, чтобы сначала зарегистрировать вашу платформу IoC, сделайте что-то вроде этого:

[assembly: WebActivator.PreApplicationStartMethod(typeof(MyApp.App_Start.NinjectWebCommon), "Start", Order=1]
[assembly: WebActivator.PreApplicationStartMethod(typeof(MyApp.App_Start.BGScheduler), "Start", Order=2]

Поскольку классы WebActivator являются статическими классами, я не вижу, как вы можете использовать в них внедрение конструктора.Вы можете , однако, используйте шаблон поиска службы (анти?) - зарегистрировав свой распознаватель IoC в качестве стандартного указателя службы Mvc, используя System.Web.Mvc.DependencyResolver.SetResolver(IDependencyResolver resolver).

Я не особо хочу идтив преимущества и недостатки шаблона поиска сервисов здесь!

Answer 2

Если вы знаете, что метод PreAppStart A должен запускаться после метода B PreAppStart, то единственный способ добиться этого - явное добавление вызова к B внутри тела A.

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