ProBiotekАртем G,

DependencyResolver же в сборке System.Web.Mvc ! Вы предлагаете ее загружать в ВинФормы ?

Не использовать резолвер, не использовать сервис локатор. Не искать способы получить статический резолвер.


Владимир Путин-ЛенинАртем GВторой вариант не нарушает каких либо принципов

говорят, что это антипаттерн ServiceLocator, но лично на мой взгляд - вполне себе вариант.

Никакой не вполне себе, сервис локатор — зло. По опыту ничего хорошего ни для разработки, ни для сопровождения, ни тем более для тестирования. Зло по всем параметрам.

ProBiotekВ MVC так и используется. Вроде все ок.

Я не использую ни в одном из своих MVC приложениях. Ни в одном, при том, что приложения построены полностью на DI.

И как это так у меня получается????

ProBiotekСобственно мой вопрос в том и заключается: как работать в WinForms. Как там, в любой точке программы получить аналог DependencyResolver, или что там в ВинФормах вместо этого.

Решать тебе конечно. Я лишь говорю, что тебе это не нужно.

ProBiotekНе соглашусь, что это сервис локатор.

Не важно, согласен ты с этим или нет, но это сервис локатор.

ProBiotekЭто просто глобальная статическая переменная на DependencyResolver. Дальше он уже используется как IOC контейнер, как и положено, типы резолвятся через него.

Это и есть сервис локатор.


ProBiotekЭто гораздо лучше, чем во все существующие классы передавать DependencyResolver :)

Передавать в классы локатор это тупость в квадрате. В классы передаются только те интерфейсы, которые он реально использует. Зачем им передавать контейнер, откуда можно всё достать? Это отвратительная архитектура, проблемы неизбежны. Но дело твоё.

ProBiotekВы предлагаете не использовать IOC ? Резолвер ведь это и есть IOC Container.

Я предлагаю использовать DI, который реализует принцип IoC.


ProBiotekИ как вы предлагаете обходится без статического резолвера ?

Легко. В ASP.NET MVC контроллеры создаются из контейнера, в конструкторе контроллера перечисляются интерфейсы, которые нужны ему для работы, и контейнер их туда подставляет. И так далее по цепочке. Нигде не нужен статический резолвер, нигде не нужно обращаться к контейнеру напрямую.

Советую изучить вопрос.


ProBiotekВ MVC то он есть, разработчики MVC и все кто этим пользуются глупцы ?

Естественно он есть, я не говорил, что контейнера нет. Я про то, что не надо его использовать. Вообще.

Владимир Путин-ЛенинЕвгенийВНикчемная новомодная штучка.

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

Пример использования в веб-формсах:




Всё, что надо зарезолвить позже, делается через фабрики или лениво.

ЕвгенийВТам все тянется через локальные данные потока.

P. S. нафига вам вообще сдались эти IoC контейнеры? Никчемная новомодная штучка.

Сдались, потому что решают ряд проблем и позволяют сосредоточиться на бизнес-задачах. Возможность что-то там В ЛЮБОМ месте написать это не лень продумать архитектуру, увесистая грабля для сопровождения и развития проекта, и практическая невозможность обеспечить вменяемое тестирование продукта и объяснение его поведения, любого участка кода.

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

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

ProBiotekВот вы все так интересно расписываете. и ваш подход явно отличается от общепринятого подхода (тот же глобальный IDependencyResolver). Не ясно правда чем ваш подход лучше.

Это не мой подход.

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

ProBiotekМожете ли вы поделить каким-то своим мелким проектом, для изучения и повышения своей квалификации ? :) Если не против, скиньте мне на почту ProBiotek@yandex.ru плиз. Может научусь чему то классному :)

Сначала изучи вопрос, литературы и информации в сети дофига.

https://www.google.ru/?gfe_rd=cr&ei=FFrVVrzwJoTAtAGIqJCQBA&gws_rd=ssl#q=dependency injection C#&safe=off&tbs=lr:lang_1ru&lr=lang_ru

ИзопропилProBiotekи ваш подход явно отличается от общепринятого подхода
общепринятый как раз у hVostt

Ты тоже тока из берлоги вчера вылез?

Изопропила что, общепринятым нынче является сеять зависимость от контейнера по всему говнокоду?

Какого ещё контейнера? Разрабатываемые компоненты вообще знать не знают ни о каком контейнере. Благодаря этому они отлично тестируются, их поведение предсказуемое и очевидное: например, если некий компонент не получает ссылку на IEmailService, то очевидно, что почту он отправлять не будет. А запрет использования всяких статических резолверов даёт гарантию, что так оно и будет.

Ты тоже не в курсе что такое DI и как он работает?

ЕвгенийВПредложи свою реализацию свойства HttpContext.Current?

Зачем? В контроллерах доступен контекст запроса, в фильтрах доступен контекст запроса, зачем я буду лезть в HttpContext.Current? Я что, враг себе?