Виндзор контейнер. Время жизни объектов в приложении ASP.NET MVC

Question

У меня есть новый проект, в котором используется контейнер Windsor для IoC.

Здесь упрощен код выполняется в установке

public void Install(IWindsorContainer container, IConfigurationStore store) 
{ 
    container.Register(Classes.FromThisAssembly().BasedOn<BaseController>().LifestyleTransient(), 
         Component.For<ISecurityManager>().ImplementedBy<SecurityManager>(), 
         Component.For<IAccountManager>().ImplementedBy<AccountManager>() 
         ........) 
} 

Информация, которую я нашел в официальном documenation недостаточно для понять в деталях эти строки.

Classes.FromThisAssembly().BasedOn<BaseController>().LifestyleTransient(), 

Эта строка в методе регистра позволяет инъекции зависимостей для всех классов в моем приложении, которые унаследованы от BaseController.

BaseController входит в комплект.

Впрыскивание не производится в другие классы, чем описано выше.

Мы показываем контейнеру, что время жизни всех классов контроллеров будет экземпляром.

Component.For<ISecurityManager>().ImplementedBy<SecurityManager>() 

Для всех контроллеров, зарегистрированных выше, если они есть в конструкторе интерфейс ISecurityManager будет введен экземпляр класса SecurityManager.

Срок службы этого SecurityManager в качестве значения по умолчанию равен Singleton. Поэтому после запуска приложения у нас будет только один экземпляр SecurityManager для всех контроллеров до конца выполнения приложения.

Являются ли мои идеи правильными? Кажется, что нет, по крайней мере потому, что LifestyleTransient() для контроллеров мне кажется странным и что введенные объекты тоже будут синглтонами.

Answer 1

Снизу вверх:

Срок службы этого SecurityManager является синглтон в качестве значения по умолчанию. Поэтому после запуска приложения у нас будет только один экземпляр SecurityManager для всех контроллеров до конца выполнения приложения.

Точно это произойдет.

Похоже, что нет, по крайней мере потому, что LifestyleTransient() для контроллеров мне кажется странным и что введенные объекты тоже будут синглтонами.

Контроллеры являются временными, поскольку они содержат HttpContext - они имеют информацию о текущем запросе пользователя и следующем ответе. Вот почему они являются переходными процессами, а не синглтонами - HttpContext для каждого запроса и создается каждый раз, когда браузер/клиент что-то запрашивает.

Таким образом, понятно, почему контроллеры имеют более короткий срок службы, чем другие сервисы. Это сильно зависит от внутренней архитектуры приложения. Если кто-то еще лучше понимает, почему - я более чем готов учиться.

Цикл/Resolve/Release Реестр контроллеров может быть сделано путем создания пользовательского контроллера фабрики и подставляя по умолчанию:

public class WindsorControllerFactory : DefaultControllerFactory 
{ 
    private readonly IKernel _kernel; 

    public WindsorControllerFactory(IKernel kernel) 
    { 
     _kernel = kernel; 
    } 

    protected override IController GetControllerInstance(RequestContext requestContext, Type controllerType) 
    { 
     if (controllerType == null) 
     { 
      throw new HttpException(404, string.Format("The controller for path '{0}' could not be found.", requestContext.HttpContext.Request.Path)); 
     } 

     if (_kernel.GetHandler(controllerType) != null) 
     { 
      return (IController)_kernel.Resolve(controllerType); 
     } 
     return base.GetControllerInstance(requestContext, controllerType); 
    } 

    public override void ReleaseController(IController controller) 
    { 
     _kernel.ReleaseComponent(controller); 
    } 
} 

и где-нибудь поставить:

container.Register(Component.For<IControllerFactory>().ImplementedBy<WindsorControllerFactory>()); 

Мои контроллеры тоже синглтон-зависимостей. Таким образом, вы можете достичь модели программирования трубопровода - вы выполняете запрос от контроллера через ряд объектов и возвращаете результаты.

Если SecurityManager имеет какое-то отношение к аутентификации или авторизации, возможно, лучше использовать механизмы MVC по умолчанию Filtering, такие как IAuthorizationFilter или AuthorizeAttribute. Конечно, это, возможно, фильтр доступа к данным, и может быть разумным поместить его в другой объект.

Я ответил на ваши вопросы?