Примерно на прошлой неделе я пытался разобраться с Windows Workflow Foundation (WF). Я прочитал множество статей (хороших мало, и далеко друг от друга), и я думаю, что наконец-то это понял. Для этого я собираюсь создать приложение для отслеживания ошибок в качестве примера создания веб-сайта на основе рабочего процесса.
Вся эта идея основана на двух прекрасных статьях Скотта Аллена. Первый — это рабочий процесс отслеживания ошибок (да, именно там я и получил идею), а второй — рабочий процесс отслеживания заказов . Я собираюсь объединить идеи обоих и попытаться создать веб-приложение для отслеживания ошибок с использованием Asp.Net MVC. Попутно я собираюсь представить внедрение зависимостей с использованием Unity, а также использовать сервисный слой и шаблон репозитория .
Шаг 1 — Использование Unity с Asp.NET MVC
Я не лучший поклонник структур внедрения зависимостей — я предпочитаю использовать «внедрение зависимостей бедняков» — предоставлять перегрузки конструктора для внедрения зависимостей (во время тестирования) и просто добавлять новую конкретную реализацию в конструктор по умолчанию. Однако для этого приложения я нашел его чрезвычайно полезным — существуют различные одноэлементные объекты, которые вам нужно передать, и Unity делает это довольно хорошо.
Чтобы начать работу, добавьте ссылку на Microsoft.Practices.Unity и Microsoft.Practices.ObjectBuilder2 . У вас есть 2 варианта настройки Unity — в коде или в конфигурационном файле xml. Я пошел по маршруту кода.
Я создаю статический класс Bootstrapper внутри моего веб-проекта — он содержит всю логику для настройки Unity. Нам нужно вызвать этот класс из нашего события Application_Start .
protected void Application_Start()
{
RegisterRoutes(RouteTable.Routes);
Bootstrapper.ConfigureUnityContainer();
}
Все идет нормально. Теперь мы просто создаем контейнер Unity и сопоставляем интерфейсы с конкретными реализациями.
var container = new UnityContainer();
container.RegisterInstance<IUnityContainer>(container);
// Services
container.RegisterType<IBugService, BugService>();
container.RegisterType<IUserService, UserService>();
// Repositories
container.RegisterType<IUserRepository, UserRepository>();
container.RegisterType<IBugRepository, BugRepository>();
Регистрация контейнера с самим собой — довольно изящная уловка — это позволяет нам использовать реальный контейнер в качестве зависимости в дальнейшем. Теперь, когда мы настроили контейнер, нам нужно использовать его, используя Unity для создания всех наших контроллеров. Для этого нам нужно создать ControllerFactory .
public class ControllerFactory : DefaultControllerFactory
{
private readonly IUnityContainer container;
public ControllerFactory(IUnityContainer container)
{
this.container = container;
}
protected override IController GetControllerInstance(Type controllerType)
{
if (controllerType == null)
{
return null;
}
else
{
return (IController)container.Resolve(controllerType);
}
}
}
Последний шаг — зарегистрировать эту фабрику в MVC — мы делаем это из Bootstrapper.
ControllerBuilder.Current.SetControllerFactory(new ControllerFactory(container));
В моем следующем посте я собираюсь разработать рабочий процесс и показать, как интегрировать доменные объекты с сохранением рабочего процесса. Я опубликую весь код в конце этой серии.
Свежие комментарии