Имеет ли смысл DI в настольном приложении?

Question

Я собираюсь создать приложение для рабочего стола (с формами окон .NET)

По сути, я хочу создать приложение n-уровня, но также хочу иметь свободную связь между слоями. Тем не менее, я не очень уверен, что это хороший подход для оконных форм.

Теперь я просто задаюсь вопросом, было бы действительно разумным выбором использовать любые IoC (StructureMap, Ninject, Spring.Net), я использовал они прежде всего для веб-приложений Asp.Net, но теперь я сомневаюсь в том, что работа с формами окон моих бизнес-сущностей будет сохраняться, когда я перемещаюсь по вкладкам и в отличие от веб-форм или приложений mvc, где было бы необходимо ввести мою бизнес-сущность для каждого нового запроса, который выполняется, я имею в виду это из-за Asp.Net page life cycle, где выполняется инициализация и контроль.

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

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

Любая точка зрения будет оценена по достоинству.

Answer 1

Он по-прежнему имеет смысл использовать DI/IoC в вашем случае, потому что это все о сдав контроль, где зависимости берутся, кто управляет их время жизни и т.д.

В этом смысле принцип Inversion of Control практически не зависит от платформы, он может работать несколько иначе с точки зрения соединения между ASP.NET и WinForms, но принцип тот же.

Итак, тогда как в ASP.NET, как правило, инверсия управления, как правило, реализована через Dependency Injection и в основном через инжекцию конструктора в контроллеры и т. Д., Что не означает, что вам нужно следовать одному и тому же шаблону в Windows Forms - например, вы можете просто создать глобальный экземпляр ваш IoC контейнер доступен для всех форм, и они получают свои depdendencies через что-то вроде

var SomeBusinessObject = container.Get<SomeBOType>(); //Ninject style. 

в этом случае это все-таки IoC (форма непосредственно не создает зависимость, она понятия не имеет, если контейнер дает это новый экземпляр или один статический экземпляр, который глобально разделен, он не знает, когда он будет уничтожен и т. д.), но это не означает строгое соответствие Зависимость Инъекция - однако вы получаете все преимущества наличия сложных графиков зависимостей, которыми управляет среда IoC.

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

Answer 2

Да, сегодня существует больше фокуса, чем когда-либо, для повторного использования существующих компонентов и проводки вместе с разрозненными компонентами для формирования сплоченной архитектуры. Но эта проводка может быстро стать сложной задачей, поскольку по мере увеличения размера приложения и сложности, так же как и зависимости. Одним из способов смягчения распространения зависимостей является использование Dependency Injection (DI), который позволяет вам вводить объекты в класс, а не полагаться на класс для создания самого объекта.

Контейнеры обеспечивают слой абстракции, в котором размещаются компоненты. Контейнеры DI, в частности, уменьшают тип связи, которую я только что описал, предоставляя общие заводские классы, которые создают экземпляры классов. Эти экземпляры затем настраиваются контейнером, что позволяет использовать логику построения на более широком уровне.

Вы можете прочитать больше here

Answer 3

Ваш вопрос нечетный. Вы сомневаетесь, что вы пишете свой бизнес-уровень для приложения Winforms по-другому, чем в веб-приложении, но если вы правильно применяете слоирование, бизнес-уровень должен быть полностью независим от используемой технологии. Поэтому в этом случае, если вы примените шаблон зависимостей зависимостей на бизнес-уровне веб-приложения, вы также должны применить его на бизнес-уровне настольного приложения.

В настоящее время я работаю над проектом Winforms и широко использую шаблон Injection Dependency (и контейнер IoC). Для меня нет вопроса, следует ли использовать DI; естественно следует применять принципы SOLID. Независимо от того, следует ли использовать контейнер IoC, это совершенно другой вопрос, хотя для типов приложений я пишу и использую типы архитектуры, я не могу представить себе жизнь без нее.

Несмотря на то, что настольные приложения отличаются по своему характеру, чем веб-приложения, я использую те же шаблоны для обоих типов приложений. Например, я использую инъекции конструктора в классах моего Windows Forms и те формы, в основном, зависят от нескольких общих интерфейсов, а именно:

• IRepository<TEntity> (шаблон репозитория) для загрузки объектов.
• IQueryHandler<TQuery, TResult> для выполнения сложных или пользовательских запросов разного рода.
• ICommandHandler<TCommand> для выполнения прецедентов (обработка действий пользователя).

Я использую те же абстракции в создаваемых веб-приложениях.

Эти интерфейсы помогли мне несколько месяцев назад, чтобы изменить это настольное приложение из двухуровневого приложения (все бизнес-логики, запущенные в настольном приложении), в трехуровневое приложение (где вся бизнес-логика теперь перемещается в WCF оказание услуг). Мы смогли сделать это без необходимости менять код в Формах.

В двухуровневой модели мы не вводили сразу ICommandHandler<TCommand> реализаций, а вводили (прокси-класс) одного прокси-класса, который создавал бы новую реализацию каждый раз, когда он был вызван. Например, когда форма, называемая впрыском ICommandHandler<ProcessOrder>, фактический CommandHandlerProxy<ProcessOrder> начнет всю жизнь (образ жизни, который имитирует образ жизни для каждого запроса в веб-приложении) и создаст реальный класс ProcessOrderCommandHandler, который будет выполнять фактическую логику.Сделав это, мы обеспечили, чтобы одна единица работы (Entity Framework DbContext в нашем случае) была бы введена во все классы в рамках этого «запроса». Все, конечно, с введением зависимостей вплоть до графика вызовов.

В новой модели 3-уровневой, формы вводятся с WcfProxyCommandHandler<TCommand>, который будет сериализовать данную команду для JSON и отправить его на службу WCF, который заберет его, десериализует команду, создает ProcessOrderCommandHandler и выполняет команду.

Но имейте в виду, что эта модель, вероятно, очень отличается от того, что вы, вероятно, использовали. Например:

• Настоящие объекты скрыты за службой WCF. Настольное приложение ничего не знает о них.
• Вместо этого DTO s возвращаются из службы WCF, когда запрашиваются данные через абстракцию IQueryHandler<TQuery, TResult>.
• Мы используем Entity Framework 5 (классы POCO с T4 и дизайнером).
• Эти DTO (в основном) используются для чтения; они не отправляются обратно на сервер для обновления.
• Любой запрос об изменении состояния (исполнение прецедента) выполняется путем отправки командного сообщения на сервер (через абстракцию ICommandHandler<TCommand>).
• Один единственный вариант использования инкапсулирован в один класс, который реализует интерфейс ICommandHandler<TCommand>.

И, как я уже сказал, это инъекция зависимостей полностью вниз, и этот и описанный дизайн дают нам большую гибкость. Например:

• Нам очень легко добавить новые функции.
• Нам очень легко добавить новые сквозные проблемы.
• Он опускает ментальный барьер; это упрощает работу приложения и значительно реже ломается неожиданными способами.

Существует, однако, одна вещь, которую я узнал в процессе:

• Связывание в WinForms оптимизирован для работы с наборами данных. Если вы попробуете что-нибудь еще (объекты Poco, Entity Framework и т. Д.), Вы получите некоторые очень неприятные моменты, когда вы узнаете, что поддержка чего-либо еще, кроме DataSets, минимальна. Понятно, что Microsoft не инвестировала в эту область и больше не будет инвестировать в эту область. Чтобы обойти эти ограничения, мы написали собственную реализацию BindingList<T> и очень сложно создать реализацию, которая корректно работает с сортировкой и фильтрацией (тем более, что наши DTO не реализуют INotifyPropertyChanged). Мы также wrote our own infrastructure добавили поддержку валидации DataAnnotations для Winforms.

Если вы хотите узнать больше о проектах, которые я использую, пожалуйста, прочитайте эти статьи:

1. Meanwhile... on the command side of my architecture
2. Meanwhile... on the query side of my architecture
3. Writing Highly Maintainable WCF Services