Алексей К,

Вот здесь подробненько

http://stackoverflow.com/questions/20061082/how-do-you-do-dependency-injection-with-autofac-and-owin

Алексей КПроблема не в контейнере, а в помойке из MVC + API + OWIN.

Мда... Проблема в голове. MVC, WebAPI, OWIN находятся на разных уровнях и решают разные задачи.

OWIN это по сути замена устаревшего нагромождения ASP.NET, Katana реализуюет OWIN поверх ASP.NET как часть переходного процесса.

Потихоньку MVC и WebAPI переезжают на новые рельсы. Не всё сразу!

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

Алексей КДа просто веселят маркетинговые формулировки.

Какие нахрен маркетинговые фурмилировки? Ну и что из этого ты купил? Названные тобой "помоечные" технологии бесплатны, и доступны в исходниках (большая часть).

Алексей КВроде работает, но как-то не очень, в OWIN используется MVC-шный DependencyResolver.

Если не хочется углубляться, остановись на этом. Нужно-то всего в одном месте, можешь не париться на этот счёт.

Алексей КГромкие слова, не подкреплённые фактами. Но это маркетинг, там свои правила.

Всё держится исключительно на маркетинге

Алексей КЭтот процесс бесконечен. Все новые технологии находятся в состоянии бесконечного полуфабриката. Почти переведут на OWIN, с приходом нового менеджера появится какой-нибудь HUYOWIN, и начнётся новый переезд. Но я привык.

Я считаю, это замечательно! Количество при таком подходе неизбежно превращается в качество.

Алексей КНет, спасибо! Такого кода мне не надо. Хочешь сделать хорошо - сделай это сам. К сожалению...

И что тебе в этом коде не нравится? А если решил свои миддлеварчики запилить, они знать не знают ни о каких DependencyResolver. Но это если решил.

Я вот запилил эксперимента ради свои OAuth провайдеры для всех популярных соц. сервисов, "коробочные" выкинул на помойку, ибо они более чем унылы.

Алексей КНо посмотрим, может в этот раз произойдёт чудо.

Я так понимаю, чем больше канючить по этому поводу, шансы на чудо увеличатся?

Алексей КИ вообще. Ну не получается если полноценным DI, ну есть же CommonServiceLocator. Почему он не используется в MVC и API? Почему там свои локаторы?

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

МСУВот http://codearticles.ru/articles/2301 На все случаи жизни, коих 99.9%

Примерно тоже самое мне говорил один старый бородатый Си-шник. Говорил, а нахрена мне эти ваши ООП-шные говно-приблуды упёрлись? Виртуальность легко реализовывается на Си, как два пальцо об освальт.

Алексей КЯ про отдельный Common ServiceLocator.

Такого в принципе быть не может. Это связано с областью времени жизни, которые в MVC и WebAPI привязаны к разным контекстам, и они никак не коррелируют.

Алексей КШансы увеличатся, если будет конкуренция. На платформе .Net Framework её к сожалению нет.

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

Алексей КФанатичная тяга к расширяющим методам в новых библиотеках в чём-то подтверждает его правоту.

Фанатичная тяга к ХХХ (подставить сюда что угодно) -- ето плохо и вредно. Этот постулат ничего не объясняет и ничего не доказывает.

Алексей КК каким к разным? Дешёвая обёртка .

это заговор!

Алексей КЭто не развитие, это тыканье-мыканье. Всё делается методом проб и грубых ошибок. Это не развитие, это деградация.

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

Короче, ниачём. Наезд, как обычно, не обоснован ничем. А нравится-ненравится, -- это лучше обсудить с блондинками на женском форуме.

Алексей КБыло приведено достаточно фактов. Но согласен, блондинок факты не интересуют. Не обижайся. :-)

Чот не заметил. Наезд из области, почему бы на весь .NET не сделать один большой ServiceLocator. Если тебе он так нужен, сделай свой -- в чём сложности? Всем не угодишь.

МСУЯ стараюсь дистанцироваться от нагромождения, лишних слоёв и абстракций. Основной аргумент - вот когда потребуется развязка, тогда и сделаем это. Тем более, это будет сделать очень легко, т.к. изначально пишется расширяемый код. Плюсы такого очевидны, я быстро поднимаю рабочее приложение без шелухи и оно начинает внятно работать, обрастать функционалом. Но можно пойти другой дорогой, накручивать слои, долго и упорно размышлять о правильности и нужности различных слабых связей, строить стены и ломать мосты. При таком подходе на выхлопе тоже получается рабочая программа. В силу фанатичности второй способ более критичен к времени реализации. Причем, еще раз подчеркну, что в любое время из первого способа можно получить второй приложив минимум усилий.

Согласен, не однократно сталкивался с излишним увлечением архитектурой, когда полезного кода (непосредственно выполняющего задачи) меньше, чем обвязки

Нахлобуч,

Так это же здорово! Посмотри какая флора и фауна, любо посмотреть!

Кроме того, никто никого не заставляет что-то использовать или на что-то переходить. Как отдельные кодили люди раньше на WebForms, так и продолжают кодить. Проекты, запиленные на MVC 3 всё так же актуальны, и большая часть NuGet-пакетов к ним без проблем подходит.

Вообще, одно появление NuGet, это уже прорыв небывалый. Как глобальные репозитории, так и локальные.

Что касается OWIN, Майкрософту необходимо было найти выход из стойла ASP.NET, чтобы оседлать другие платформы (Linux, OS X), и OWIN для этого хорошо подходит. Не надо думать, что это просто потому, что кто-то дескать сочинил, а потом "а пуркуа бы не па" -- это похоже на мышление маленького ребёнка. Ничего не делается просто так.

Вообще эволюция, любая, какая бы она ни была, всегда идёт по пути экспериментов, через череду неудач.

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

Это нытьё по поводу того, что кто-то там, дескать, как-то не так сделал... Как обычно, забыли самого умного спросить.

НахлобучПроблема тут двоякая. С одной стороны, в .NET не так развита культура OSS-проектов (достаточно посмотреть на статистику на том же ГитХабе). А с другой, есть некая неприязнь к не-Microsoft проектам, когда какую-то библиотеку отказываются использовать только потому, что она не поставляется вместе с .NET или Visual Studio. И наоборот, отдается предпочтение заведомо более "ущербным" "встроенным" аналогам.

Нет никакой проблемы, у майкрософта своя культура, и она имеет все права на неё. На счёт неприязни, не согласен совершенно. У кого-то есть такая неприязнь, у кого-то нет. Я использую коробочные либы, если они решают свои задачи. Если нет, использую сторонние или пишу свои. Конечно в первую очередь я смотрю на то, что есть в коробке, никакой неприязни не испытываю. Проблема надуманная.

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

Не согласен, для открытого репозитария Майкрософт должна была переступить некую свою черту. Им надо продавать, а не помогать распространению халявы. Ты же не работаешь забесплатно, нет? Так почему они должны? Суть прорыва не в новизне, а в самом факте. И это очень круто, я считаю!

НахлобучОй сомневаюсь в желании поддерживать другие платформы. У Microsoft свой стек технологий (начиная от ОС и заканчивая веб-сервером и СУБД) и вот так вот взять и "поддержать Linux"?

Учитывая определённый успех Линкусов на поприще серверных технологий, Майкрософт не имеет экономического права игнорировать этот факт. Поддерживать не обязана, но и упускать рынок нет смысла. С недавних пор они начали понимать, что не всегда можно перекроить мир под себя, иногда выгодней подстроиться.

НахлобучТолько вот эти планы меняются каждый год.

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

НахлобучБесспорно. Но можно учиться не только на своих, а еще и на чужих ошибках, чтобы каких-то неудач и не допускать. Например, под воздействием каких веществ был рожден неимоверно раздутый MembershipProvider ? Или какой укурок придумал хранить в одном NuGet-пакете сборки для разных платформ и версий .NET Framework? Сколько можно было рожать Middleware (и так толком и не родить)?

Я очень сомневаюсь, что находясь в самом начале пути, не имея никакого фидбека, нашлось бы много людей, которые могли бы сделать лучше.

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

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

НахлобучИ давай-ка воздержись от переходов на личности.

Где ты подобное увидел?

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

Никто не обязывает использовать. Пиши свой провайдер. Часто так и делают.