Цель блока приложений единицы в Microsoft Enterprise Library?
Я создал бы службу Windows (тип проекта Visual Studio 2005 года), который обрабатывает событие OnSessionChange как показано ниже:
protected override void OnSessionChange(SessionChangeDescription changeDescription)
{
if (changeDescription.Reason == SessionChangeReason.SessionLock)
{
//I left my desk
}
else if (changeDescription.Reason == SessionChangeReason.SessionUnlock)
{
//I returned to my desk
}
}
то, Какой и как Вы регистрируете действие в той точке, ваше дело, но служба Windows обеспечивает быстрый и легкий доступ к событиям окон как запуск, завершение работы, вход в систему/, наряду с блокировкой, и разблокируйте события.
2 ответа
Инверсия управления
Быстрое суммирование (в этой теме доступно гораздо больше чтения, и я настоятельно рекомендую прочитать больше) ...
Microsoft Unity от группы Enterprise Patterns and Practices - это контейнерный проект Inversion of Control, или сокращенно IoC. Так же, как Castle Windsor, StructureMap и т. Д. Этот тип разработки также упоминается в терминах ламена как Слабое связывание ваших компонентов.
IoC включает шаблон для внедрения зависимостей ваших объектов, в котором вы полагаетесь на внешний компонент для подключения зависимости внутри ваших объектов.
Например, вместо доступа к статическим менеджерам (которые практически невозможно выполнить модульное тестирование), вы создаете объект, который полагается на внешнюю зависимость. Возьмем почтовый сервис, в котором вы хотите получить доступ к БД для получения сообщения.
public class PostService : IPostService
{
private IPostRepository _postRepo;
public PostService(IPostRepository postRepo)
{
_postRepo = postRepo;
}
public IList<Post> GetPosts()
{
return _postRepo.GetAllPosts().ToList();
}
}
Этот объект PostService теперь имеет внешнюю зависимость от IPostRepository. Заметили, что не используются бетоны и статические классы менеджеров? Вместо этого у вас есть слабая связь простого интерфейса, который дает вам возможность подключать все различные виды конкретных классов, реализующих IPostRepository.
Цель Microsoft Unity - подключить этот IPostRepository для вы, автоматически. Так что вам никогда не придется беспокоиться о том, чтобы сделать:
// you never have to do this with Unity
IPostRepository repo = new PostRepository();
IPostService service = new PostService(repo); // dependency injection
IList<Post> posts = service.GetPosts();
Выше показано, где вам нужно реализовать два конкретных класса: PostRepository () и PostService (). Это сильно привязывает ваше приложение к требованию / требованию именно этих экземпляров и очень затрудняет модульное тестирование.
Вместо этого вы должны использовать Unity в своей конечной точке (контроллер в MVC или код на страницах ASPX):
IUnityContainer ioc = new UnityContainer();
IPostService postService = ioc.Resolve<IPostService>();
IList<Post> posts = postService.GetPosts();
Обратите внимание, что в этом примере не используются конкретные элементы (кроме UnityContainer и Post, очевидно)! Ни конкретики сервисов, ни репозитория. Это слабая связь в лучшем виде.
Вот настоящий кикер ...
Unity (или любой другой инфраструктурный контейнер IoC!) Будет проверять IPostService на наличие любых зависимостей. Он увидит, что хочет (зависит) от экземпляра IPostRepository. Итак, Unity войдет в свою карту объектов и найдет первый объект, реализующий IPostRepository, который был зарегистрирован в контейнере, и вернет его (то есть экземпляр SqlPostRepository). В этом реальная сила фреймворков IoC - способность проверять службы и автоматически подключать любые зависимости.
Мне нужно закончить мой блог о сравнении UNity, Castle и StructureMap. На самом деле я предпочитаю Castle Windsor из-за его параметров файла конфигурации и точек расширения лично.
Блок приложения Unity используется для внедрения зависимостей . Я думаю, что лучшее простое определение для DI взято из этого вопроса
Когда вы идете и достаете вещи из холодильника для себя, вы можете создать проблемы. Вы можете оставить дверь открытой, вы можете получить что-то, чего мама или папа не хотят, чтобы вы имели. Возможно, вы даже ищете что-то, чего у нас нет или срок годности которого истек.
Вы должны указать: «Мне нужно что-нибудь выпить за обедом», и тогда мы позаботимся о том, чтобы у вас что-то было когда вы садитесь поесть.
Так, например,
IUnityContainer container = new UnityContainer();
ILunch lunch = container.Resolve<ILunch>();
Console.WriteLine(lunch.Drink);
This Outputs «Lemonade», потому что мы определили Drink как зависимость.
public class ILunch {
[Dependency]
public IDrink Drink { get; set; }
}
Что касается практичности, то Внедрение зависимостей действительно здорово, когда у вас есть зависимости от других объектов, и вы не хотите, чтобы разработчик устанавливал их вручную. Это так просто. Это также отлично подходит для издевательств. Самый часто используемый пример, который я использую, - это имитация уровня данных. Иногда база данных не готова, поэтому вместо остановки разработки у меня есть поддельный слой, который возвращает поддельные данные. Доступ к объекту данных осуществляется через DI, и он может быть сконфигурирован для возврата объектов, которые обращаются к поддельному или реальному слою. В этом примере я почти использую контейнер DI как настраиваемый фабричный класс. Для получения дополнительной информации о Unity MSDN предлагает отличные ресурсы http://msdn.microsoft.com/en-us/library/cc468366.aspx .
Другие хорошие платформы DI включают Spring. NET и Ninject