Сначала некоторые концептуальные детали.В приложении ASP.NET MVC типичной точкой входа для запроса страницы является контроллер.Мы хотим, чтобы контейнер Inversion of Control разрешал наши контроллеры за нас, потому что тогда любые зависимости, которые есть у контроллеров, также могут быть автоматически разрешены путем простого перечисления зависимостей в качестве аргументов в конструкторах контроллеров.
Еще не запутались?Вот пример того, как вы будете использовать IoC после того, как все настроено.Я думаю, что объяснение таким образом облегчает задачу!
public class HomeController : Controller
{
// lets say your home page controller depends upon two providers
private readonly IMembershipProvider membershipProvider;
private readonly IBlogProvider blogProvider;
// constructor, with the dependencies being passed in as arguments
public HomeController(
IMembershipProvider membershipProvider,
IBlogProvider blogProvider)
{
this.membershipProvider = membershipProvider;
this.blogProvider = blogProvider;
}
// so taking your Registration example...
[HttpPost]
public ActionResult Register( Web.Models.Authentication.Registration model)
{
if (ModelState.IsValid)
{
this.membershipProvider.CreateUser(model.Email, model.Password);
}
// If we got this far, something failed, redisplay form
return View(model);
}
}
Обратите внимание, что вам не приходилось решать самостоятельно, вы просто указали в контроллере, каковы зависимости.Вы также не указали, как реализованы зависимости - все это разъединено .Это очень просто, здесь нет ничего сложного: -)
Надеемся, что в этот момент вы спрашиваете: "а как конструктор создается?"Именно здесь мы начинаем настраивать ваш контейнер Castle, и мы делаем это полностью в MVC Web проекте (не в постоянстве или домене) .Отредактируйте файл Global.asax, установив Castle Windsor в качестве фабрики контроллеров:
protected void Application_Start()
{
//...
ControllerBuilder.Current
.SetControllerFactory(typeof(WindsorControllerFactory));
}
... и определите WindsorControllerFactory, чтобы ваши контроллеры создавались Windsor:
/// Use Castle Windsor to create controllers and provide DI
public class WindsorControllerFactory : DefaultControllerFactory
{
private readonly IWindsorContainer container;
public WindsorControllerFactory()
{
container = ContainerFactory.Current();
}
protected override IController GetControllerInstance(
RequestContext requestContext,
Type controllerType)
{
return (IController)container.Resolve(controllerType);
}
}
Метод ContainerFactory.Current() - это статический синглтон, который возвращает настроенный контейнер Castle Windsor.Конфигурация контейнера инструктирует Windsor о том, как разрешить зависимости вашего приложения.Например, у вас может быть контейнер, сконфигурированный для разрешения NHibernate SessionFactory, и ваш IMembershipProvider.
Мне нравится конфигурировать мой контейнер Castle с использованием нескольких «установщиков».Каждый установщик отвечает за различные типы зависимостей, поэтому у меня должен быть установщик Controller , установщик NHibernate , например установщик Provider .
Сначала у нас есть ContainerFactory:
public class ContainerFactory
{
private static IWindsorContainer container;
private static readonly object SyncObject = new object();
public static IWindsorContainer Current()
{
if (container == null)
{
lock (SyncObject)
{
if (container == null)
{
container = new WindsorContainer();
container.Install(new ControllerInstaller());
container.Install(new NHibernateInstaller());
container.Install(new ProviderInstaller());
}
}
}
return container;
}
}
... а затем нам нужен каждый из установщиков.ControllerInstaller first:
public class ControllerInstaller : IWindsorInstaller
{
public void Install(IWindsorContainer container, IConfigurationStore store)
{
container.Register(
AllTypes
.FromAssembly(Assembly.GetExecutingAssembly())
.BasedOn<IController>()
.Configure(c => c.Named(
c.Implementation.Name.ToLowerInvariant()).LifeStyle.PerWebRequest));
}
}
... а вот мой NHibernateInstaller, хотя он отличается от вашего, вы можете использовать свою собственную конфигурацию.Обратите внимание, что я использую один и тот же экземпляр ISessionFactory каждый раз, когда один из них разрешен:
public class NHibernateInstaller : IWindsorInstaller
{
private static ISessionFactory factory;
private static readonly object SyncObject = new object();
public void Install(IWindsorContainer container, IConfigurationStore store)
{
var windsorContainer = container.Register(
Component.For<ISessionFactory>()
.UsingFactoryMethod(SessionFactoryFactory));
}
private static ISessionFactory SessionFactoryFactory()
{
if (factory == null)
{
lock (SyncObject)
{
if (factory == null)
{
var cfg = new Configuration();
factory = cfg.Configure().BuildSessionFactory();
}
}
}
return factory;
}
}
И, наконец, вы захотите определить свой ProvidersInstaller:
public class ProvidersInstaller : IWindsorInstaller
{
public void Install(IWindsorContainer container, IConfigurationStore store)
{
var windsorContainer = container
.Register(
Component
.For<IMembershipProvider>()
.ImplementedBy<SubjectQueries>())
.Register(
Component
.For<IBlogProvider>()
.ImplementedBy<SubjectQueries>());
// ... and any more that your need to register
}
}
Thisдолжно быть достаточно кода, чтобы начать работу! Надеюсь, вы все еще со мной, так как красота контейнера Castle станет очевидна очень скоро.
Когда вы определяете реализацию вашего IMembershipProvider в слое постоянства, помните, что он имеетзависимость от NHibernate ISessionFactory.Все, что вам нужно сделать, это:
public class NHMembershipProvider : IMembershipProvider
{
private readonly ISessionFactory sessionFactory;
public NHMembershipProvider(ISessionFactory sessionFactory)
{
this.sessionFactory = sessionFactory;
}
}
Обратите внимание, что, поскольку Castle Windsor создает ваши контроллеры, а провайдеры передаются в ваш конструктор контроллеров, провайдеру автоматически передается реализация ISessionFactory, настроенная в вашем Виндзоре.контейнер!
Вам больше не нужно беспокоиться о создании каких-либо зависимостей снова.Ваш контейнер делает все это автоматически для вас.
Наконец, обратите внимание, что IMembershipProvider должен быть определен как часть вашего домена, так как он определяет интерфейс поведения вашего домена.Как отмечалось выше, реализация интерфейсов вашего домена, которые работают с базами данных, добавляется на уровень постоянства.