powered by simpleCommunicator - 2.0.59     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / ASP.NET [игнор отключен] [закрыт для гостей] / выбор IoC
286 сообщений из 286, показаны все 12 страниц
выбор IoC
    #38473821
handmadeFromRu
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
чисто ради интереса кто-нибудь выбирает контейнер исходя из к примеру http://www.palmmedia.de/blog/2011/8/30/ioc-container-benchmark-performance-comparison , или как сложилось и тем пользуется? По идее время отдачи экземпляра не совсем спички так как обращения к контейнеру идут довольно часто.

п.с. сам как то подсел на Autofac и дальше не слезал.
...
Рейтинг: 0 / 0
выбор IoC
    #38473836
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Я за родные DI контейнеры: http://msdn.microsoft.com/en-us/library/dd203101.aspx
Если MVC, то DI контейнер доступен в самом фреймворке, так что ничего дополнительно ставить не нужно.

Всё остальное на помойку.
...
Рейтинг: 0 / 0
выбор IoC
    #38473878
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
handmadeFromRu,

Autofac. более логичной имплементации среди DI для .NET пока не встречал. везде что-нибудь, да через Ж. особенно убогий Unity.
...
Рейтинг: 0 / 0
выбор IoC
    #38473892
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУЕсли MVC, то DI контейнер доступен в самом фреймворке, так что ничего дополнительно ставить не нужно.

чо за бред ты несёшь? ты поддержку от реализации отличаешь?
...
Рейтинг: 0 / 0
выбор IoC
    #38473898
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttчо за бред ты несёшь?
Не бросай слюну по сторонам, чтобы опять стыдно не было. По факту - что конкретно тебя интересует?

hVosttты поддержку от реализации отличаешь?
MVC поддерживает и реализует DI контейнер и фабрику. Что тебя смущает?
...
Рейтинг: 0 / 0
выбор IoC
    #38473905
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
handmadeFromRuвремя отдачи экземпляра не совсем спички так как обращения к контейнеру идут довольно часто

в рамках жизненного цикла, повторные запросы возвращают объекты максимально быстро. для критичных мест, можно отдавать фабрику вместо объекта, также можно задать вызов контруктора вручную, также можно отдавать по ключу и по индексу. ещё можно кешировать. в Autofac всё это делается очень гибко.
...
Рейтинг: 0 / 0
выбор IoC
    #38473913
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУMVC поддерживает и реализует DI контейнер и фабрику. Что тебя смущает?

смущает конечно. где ты там контейнер увидел? не говори, что DependencyResolver
...
Рейтинг: 0 / 0
выбор IoC
    #38473919
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
handmadeFromRuПо идее время отдачи экземпляра не совсем спички так как обращения к контейнеру идут довольно часто.
Если у тебя это критичное место (циклы, многопоточность и т.п.), почему бы вначале не отресолвить объекты, а потом использовать их инстансы в нужном месте? Каждой задаче - свой подход, не всегда в лоб это хорошо.

hVosttсмущает конечно. где ты там контейнер увидел? не говори, что DependencyResolver
Именно DependencyResolver в данном случае является DI контейнером.
...
Рейтинг: 0 / 0
выбор IoC
    #38473926
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУИменно DependencyResolver в данном случае является DI контейнером.

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

признавайся. пил вчера?
...
Рейтинг: 0 / 0
выбор IoC
    #38473931
handmadeFromRu
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
давай только без ругани) я просто хотел узнать кто что юзает и почему) пример со ссылкой привел как возможный фактор выбора контейнера для кого то
...
Рейтинг: 0 / 0
выбор IoC
    #38473936
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttэто сервис локатор .

Садись - двойка.

DependencyResolverПредоставляет точку регистрации для сопоставителей зависимостей, реализующих IDependencyResolver или интерфейс локатора общей службы IServiceLocator.

Локатор предоставляет точку регистрации для локатора? Мало масляное

hVosttникакие зависимости MVC не разруливает, потому что никакой контейнер он не реализует. вместо этого он предоставляет точки расширения в виде фабрик, куда легко подставляется нужный контейнер, хоть Unity, хоть Autofac, хоть что-угодно-другое.
Он регистрирует и сопоставляет. Это основное, что делает DI. Всякие управления жизнью и прочие фантики - навороты, которые чаще всего просто не нужны. Что-то типа простенького модного SimpleIoC. Учи матчать.


hVosttпризнавайся. пил вчера?
Нет. А ты?
...
Рейтинг: 0 / 0
выбор IoC
    #38473937
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
handmadeFromRuдавай только без ругани) я просто хотел узнать кто что юзает и почему) пример со ссылкой привел как возможный фактор выбора контейнера для кого то

если используешь IoC, главное это удобство и логичность использования. если тебе использовать выбранный DI контейнер удобно, значит сделал верный выбор. скорость резолва не существенна. правда, если уже ранее зарезолвенный объект контейнер отдаёт всё равно медленно, то сразу в топку его
...
Рейтинг: 0 / 0
выбор IoC
    #38473943
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУСадись - двойка.

млять. главное, держу в руках книжку от Microsoft, где черным по белому написано, что DependencyResolver в ASP.NET MVC это Service Locator, и целая глава накалякана про отличия SL от DI... будешь продолжать возражать?? не позорься уж.

МСУЭто основное, что делает DI

двойешник-колышнек ты. основное отличие DI от SL:

SL — класс запрашивает внешний компонент для получения его зависимостей
DI — класс получает зависимости через конструктор (или открытые свойства)

типа. матчасть дуй учить
...
Рейтинг: 0 / 0
выбор IoC
    #38473967
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttМСУСадись - двойка.
млять. главное, держу в руках книжку от Microsoft, где черным по белому написано, что DependencyResolver в ASP.NET MVC это Service Locator, и целая глава накалякана про отличия SL от DI... будешь продолжать возражать?? не позорься уж.
Это раньше его по привычке так называли. Смотри, вот подтверждение:
http://www.asp.net/mvc/tutorials/hands-on-labs/aspnet-mvc-4-dependency-injection IDependencyResolver interface replaces the previous IMvcServiceLocator. Implementers of IDependencyResolver must return an instance of the service or a service collection.

На данный момент DependencyResolver может служить полноценным DI контейнером, который и регистрирует и сопоставляет. Кроме того, доступна фабрика DefaultControllerFactory, которую можно инициализировать через ControllerBuilder.Current.SetControllerFactory. Это еще более расширяет IoC функционал, особенно это полезно для инъекции в конструктор контроллера. То есть, сопоставлением в MVC занимается не только DependencyResolver. Всё это полноценные DI контейнеры.

hVosttдвойешник-колышнек ты. основное отличие DI от SL:

SL — класс запрашивает внешний компонент для получения его зависимостей
DI — класс получает зависимости через конструктор (или открытые свойства)

типа. матчасть дуй учить

Бездарность :)

DependencyResolver может и запрашивать и получать. Документацию читал?
...
Рейтинг: 0 / 0
выбор IoC
    #38473980
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУDependencyResolver может и запрашивать и получать. Документацию читал?

у меня книжка по MVC 4, на инглише не так уж и давно пришла из Амазона. да читал. и по букве доки там от DI только поддержка . инъекция не выполняется . как можно говорить о Dependency Injection без Injection?

это логика, Спок (с)
...
Рейтинг: 0 / 0
выбор IoC
    #38473985
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУ,

ну умора....

1. перейди по ссылке которую ты дал http://www.asp.net/mvc/tutorials/hands-on-labs/aspnet-mvc-4-dependency-injection

2. Нажми Ctrl-F и вставь "No parameterless constructor defined for this object"

не дошло? без Unity/Autofac/Ninject ты не получишь никакого DI. даже близко.
...
Рейтинг: 0 / 0
выбор IoC
    #38473989
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Хвост, вот эта инфа из букваря окончательно тебя опустит ниже плинтуса. Я же знаю, как ты не любишь читать доки

The Service Locator Pattern

Идет описание паттерна. А внизу:

Related PatternsThe following patterns are related to the Service Locator pattern:
Dependency Injection. This pattern solves the same problems as the Service Locator pattern, but it uses a different approach.
Inversion of Control. The Service Locator pattern is a specialized version of this pattern. It inverts an application's traditional flow of control. It is the object that is called instead of the caller that controls a process.

А теперь логическая нить, с которой у тебя обычно проблемы.

1. DI и IoC - это родственные паттерны, Service Locator - отдельная песня.
2. DependencyResolver может инжектировать. Следовательно, удовлетворяет первому пункту (паттерн Dependency Injection).
3. DependencyResolver поддерживает инверсию, он может сопоставлять. Следовательно, удовлетворяет второму пункту (паттерн Inversion of Control).

DummyDependencyResolver
Код: c#
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
public class DummyDependencyResolver : System.Web.Mvc.IDependencyResolver
{
    public object GetService(Type serviceType)
    {
        if (serviceType.Equals(typeof(IDataService)))
        {
            return new SqlDataService();
        }
        return null;
    }

    public IEnumerable<object> GetServices(Type serviceType)
    { 
        return Enumerable.Empty<object>();
    }
}



Код: c#
1.
DependencyResolver.SetResolver(new DummyDependencyResolver());



Код: c#
1.
var service = DependencyResolver.Current.GetService<IDataService>();



Присаживайся. Сегодня опять двойка
...
Рейтинг: 0 / 0
выбор IoC
    #38473992
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttМСУ,

ну умора....

1. перейди по ссылке которую ты дал http://www.asp.net/mvc/tutorials/hands-on-labs/aspnet-mvc-4-dependency-injection

2. Нажми Ctrl-F и вставь "No parameterless constructor defined for this object"

не дошло? без Unity/Autofac/Ninject ты не получишь никакого DI. даже близко.

Рассмешил

Срочно бежать читать про IControllerFactory. Если лень читать доки, возьми у меня готовый рецепт: http://codearticles.ru/articles/2351

Никаких Unity/Autofac/Ninject, всё работает на штатном функционале MVC. Вот пример параметризации конструктора:

Код: c#
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
public class HomeController : Controller
{
    private IDataService DataService;

    [DefaultConstructor]
    public HomeController(IDataService service)
    {
        this.DataService = service;
    }
}



Опять двойка, сударь?
...
Рейтинг: 0 / 0
выбор IoC
    #38473997
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУ,


МСУ1. DI и IoC - это родственные паттерны, Service Locator - отдельная песня.

DI и SL родственные паттерны. в IoC это архитектурный принцип (а не паттерн).

МСУ2. DependencyResolver может инжектировать.

не может и никогда не будет. потому что это Service Locator. в чистом виде.

МСУ3. DependencyResolver поддерживает инверсию, он может сопоставлять.

он не может поддерживать инверсию. это абсурдное по своей сути утверждение.



прекращай дёргать инфу из букваря. и попробуй в чистый проект MVC без юнити и других контейнеров, добавить в любой контроллер зависимость в виде конструктора. в результате будет ошибка выполнения. фабрика не сможет создать экземпляр контроллера, и прямым текстом тебе об этом скажет "иди учи матчасть"
...
Рейтинг: 0 / 0
выбор IoC
    #38474007
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУРассмешил

Срочно бежать читать про IControllerFactory. Если лень читать доки, возьми у меня готовый рецепт: http://codearticles.ru/articles/2351

Никаких Unity/Autofac/Ninject, всё работает на штатном функционале MVC. Вот пример параметризации конструктора:

во-первых, это исключительно реализация фабрики, а не DependencyResolver, и она не станет разруливать дочерние зависимости. проверь.
...
Рейтинг: 0 / 0
выбор IoC
    #38474013
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttDI и SL родственные паттерны. в IoC это архитектурный принцип (а не паттерн).
Не нужно тут коверкать своим википедийным языком. В доке MS четко написано: Inversion of Control - The Service Locator pattern is a specialized version of this pattern. Принцип, паттерн, подход... Решил позаниматься буквоедством, человек?

hVosttМСУ2. DependencyResolver может инжектировать.
не может и никогда не будет. потому что это Service Locator. в чистом виде.
Лично этот класс не может, но у него есть штатный помощник - IControllerFactory :)

hVosttМСУ3. DependencyResolver поддерживает инверсию, он может сопоставлять.
он не может поддерживать инверсию. это абсурдное по своей сути утверждение.
Resolve - чем тебе не инверсия? В чем обсурдность?

hVosttпрекращай дёргать инфу из букваря. и попробуй в чистый проект MVC без юнити и других контейнеров, добавить в любой контроллер зависимость в виде конструктора. в результате будет ошибка выполнения. фабрика не сможет создать экземпляр контроллера, и прямым текстом тебе об этом скажет "иди учи матчасть"
Я тебе дал ссылку на рецепт. Изучи нативные возможности MVC :)
...
Рейтинг: 0 / 0
выбор IoC
    #38474016
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttво-первых, это исключительно реализация фабрики, а не DependencyResolver, и она не станет разруливать дочерние зависимости. проверь.
Слушай, ну тут уже пошло меряние пиписьками. Я тебе изначально сказал, что это не тот богатый функционал, который есть в Unity, автофаках и прочей ипостаси. Ты чем читаешь?
...
Рейтинг: 0 / 0
выбор IoC
    #38474031
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУВ доке MS четко написано: Inversion of Control - The Service Locator pattern is a specialized version of this pattern

SL является паттерном, реализующим IoC. всё правильно. только IoC это не паттерн. не может быть паттерна. ты ещё скажи, что "разделяй и властвуй" — тоже паттерн.

МСУЛично этот класс не может, но у него есть штатный помощник - IControllerFactory :)

это тебя заносит... если я в качестве реализации IControllerFactory подсуну класс, размечающий и форматирующий харды, это что получается, IControllerFactory ещё и офигенная утилита для управления дисками?? если ты чего-то туда запихал — свою кастрированную реализацию подобия DI, это не называется нативной поддержкой . иначе, любой человек — это президент в чистом виде, осталось только наделить его полномочиями.

не неси ерунду. признай что глупость сказал
опростоволосился!

МСУЯ тебе дал ссылку на рецепт. Изучи нативные возможности MVC :)

ты мне дал ссылку на кастомную реализацию DI. и ещё хватает смелости называть это нативной реализацией?? ну харе уже чушь-то пороть!

в чистом ASP.NET MVC нет никакого DI.

но есть возможность запихнуть свой говнокод в фабрику или поставить Autofac
...
Рейтинг: 0 / 0
выбор IoC
    #38474036
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttэто не называется нативной поддержкой

тьфу, поддержка-то есть... нативного DI нету
...
Рейтинг: 0 / 0
выбор IoC
    #38474046
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Хвост, смотри, локатор только ищет и всё. Что следует даже из его названия.

То есть вот это поведение чисто локатора, не спорю:

Код: c#
1.
var service = DependencyResolver.Current.GetService<IDataService>();



А DependencyResolver может делать еще и так:

IDependencyResolver
Код: c#
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
public class DummyDependencyResolver : System.Web.Mvc.IDependencyResolver
{
    public object GetService(Type serviceType)
    {
        if (serviceType.Equals(typeof(IDataService)))
        {
            return new SqlDataService();
        }
        return null;
    }

    public IEnumerable<object> GetServices(Type serviceType)
    { 
        return Enumerable.Empty<object>();
    }
}



И даже вот так:

Код: c#
1.
DependencyResolver.SetResolver(new DummyDependencyResolver());



То есть это уже контейнер, получается. Да, без навороченных управлений life time, без непосредственного инжектирования - для этого есть фабрика, можно использовать её. Да и инжектирование многим не нужно, достаточно просто резолвить по месту требования. Лично я в MVC не использую инжектинг через фабрику - у меня в базовом контроллере поднимаются с помощью Lazy через инверсию все репозитории (контексты) и доступны в унаследованных контроллерах.
...
Рейтинг: 0 / 0
выбор IoC
    #38474060
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУА DependencyResolver может делать еще и так:



всё! я теперь понял что в книжке имелось в виду, что DependencyResolver очень часто путают с DI из-за приведённой тобой возможности.

да, такое поведение сильно размывает применимое к нему понятие Service Locator. но всё же. это SL.

основная причина этому объяснению — это то, что в MVC нет нативной возможности зарегистрировать типы Outside (принцип внешней управляемой зависимости). всей информацией он должен обладать, посему это не более чем шикарная возможность для установки своего полноценного контейнера DI.
...
Рейтинг: 0 / 0
выбор IoC
    #38474063
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttSL является паттерном, реализующим IoC. всё правильно. только IoC это не паттерн. не может быть паттерна. ты ещё скажи, что "разделяй и властвуй" — тоже паттерн.
MS пишет, что паттерн. Да какая разница, я не занимаюсь буквоедством, в отличие от тебя, - для меня всё это практики, паттерны, подходы. Не будь похож на прыщавого студента, который цепляется к словам, повышая свою самооценку. Смешно, ей богу

hVosttэто тебя заносит... если я в качестве реализации IControllerFactory подсуну класс, размечающий и форматирующий харды, это что получается, IControllerFactory ещё и офигенная утилита для управления дисками??
Я тебе сказал, как с помощью IControllerFactory решить задачу инъекции, если она тебе так нужна. Причем тут харды?

hVosttне неси ерунду. признай что глупость сказал
опростоволосился!
А ты забавный Читай буквари, хватит писать глупости на форуме. Вчера ты тоже с пеной у рта мне доказывал, что лямбда в LINQ компилируется в... Expression. Пришлось откровенно над тобой поглумиться и убить твой моск об документацию :)
Не разжигай (с)

hVosttМСУЯ тебе дал ссылку на рецепт. Изучи нативные возможности MVC :)
ты мне дал ссылку на кастомную реализацию DI. и ещё хватает смелости называть это нативной реализацией?? ну харе уже чушь-то пороть!
1. Фабрика - это не DI.
2. Ты сам вот тут ляпнул, что:

hVosttНажми Ctrl-F и вставь "No parameterless constructor defined for this object"
не дошло? без Unity/Autofac/Ninject ты не получишь никакого DI. даже близко.

А я тебе без Unity/Autofac/Ninject решил задачу. Как мне это удалось? Элементарно, Ватсон - я колдую по ночам

hVosttв чистом ASP.NET MVC нет никакого DI.
Есть, DependencyResolver. Не такой унылый как локатор, не такой крутой как Unity/Autofac/Ninject. Но таки это DI контейнер.
...
Рейтинг: 0 / 0
выбор IoC
    #38474065
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУЛично я в MVC не использую инжектинг через фабрику - у меня в базовом контроллере поднимаются с помощью Lazy через инверсию все репозитории (контексты) и доступны в унаследованных контроллерах.

а как же инжектинг в фильтры? как же инверсия на аспектах? инжектинг во вью? наследование хорошо для разработки библиотек, но для конечных приложений больше подходит чистый DI и аггрегация.
...
Рейтинг: 0 / 0
выбор IoC
    #38474071
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУА я тебе без Unity/Autofac/Ninject решил задачу. Как мне это удалось? Элементарно, Ватсон - я колдую по ночам

ты вместо U/A/N подсунул CustomControllerFabric. там еще и не такую магию можно делать. но ж даже не смешно. где твоя нативность? нативность, это создал проект, зарегал типы, определил в своём контроллере зависимость и получил результат.

но в твоём случае, надо ещё полезть и произвести замену родной фабрики на свою. не по правилам играешь!
...
Рейтинг: 0 / 0
выбор IoC
    #38474072
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttМСУА DependencyResolver может делать еще и так:



всё! я теперь понял что в книжке имелось в виду, что DependencyResolver очень часто путают с DI из-за приведённой тобой возможности.

да, такое поведение сильно размывает применимое к нему понятие Service Locator.

Ну наконец-то!!!

...


hVosttно всё же. это SL.
Вот же ты вредный

hVosttполноценного контейнера DI.
Отлично сказал. А теперь озвучь пункты полноценности DI. И не забудь уточнить, кто именно определил эти пункты.
...
Рейтинг: 0 / 0
выбор IoC
    #38474076
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttа как же инжектинг в фильтры? как же инверсия на аспектах? инжектинг во вью
Точно так же, в реализации фильтра я честно резолвлюсь. Вью у меня получает всё из вью модели.
И да, по поводу аспектов - скажи пожалуйста, есть ли какая-либо разница, например, между соединением транзитного Меркурия с натальным Марсом и транзитного Марса с натальным Меркурием? То есть, имеется в виду инверсия планет. Или транзитного Нептуна к натальному Плутону и транзитного Плутона к натальному Нептуну.

hVosttнаследование хорошо для разработки библиотек, но для конечных приложений больше подходит чистый DI и аггрегация.
А ты смешной :)
...
Рейтинг: 0 / 0
выбор IoC
    #38474084
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttты вместо U/A/N подсунул CustomControllerFabric. там еще и не такую магию можно делать. но ж даже не смешно. где твоя нативность? нативность, это создал проект, зарегал типы, определил в своём контроллере зависимость и получил результат.

Хватит писать глупости. Чем выше требования, тем больше функционала. То есть обсуждение имеет место для конкретного функционла, я уже об этом писал. Мне вполне устроить мотоцикл, а не самосвал. Мысль понятна?

hVosttно в твоём случае, надо ещё полезть и произвести замену родной фабрики на свою. не по правилам играешь!
Я тебе решил задачу. Если ты хочешь этот функционал в DI, возьми DI помощнее. Это же не значит, что если в автофаке есть что-то, чего нету в юнити, значит юнити на DI? Тут тоже так. MS наделили DependencyResolver минимальным набором, которого хватает 99% разработчикам. Для чего-то более серьезного - бери самосвал.
...
Рейтинг: 0 / 0
выбор IoC
    #38474089
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУОтлично сказал. А теперь озвучь пункты полноценности DI. И не забудь уточнить, кто именно определил эти пункты.

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

должна быть точка регистрации всех зависимостей таким образом, чтобы она происходила снаружи (каждый подключаемый модуль сам регистрирует все свои типы). контейнер ни о каких типах ничего знать не должен.

я незнаю почему ты так снисходительно относишься к Lifetime Scope, но без управления жизненным циклом объектов DI-контейнер что безрукий кастрат.
...
Рейтинг: 0 / 0
выбор IoC
    #38474094
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУА ты смешной :)

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

получается не я смешной.. не сам же я это выдумал.
...
Рейтинг: 0 / 0
выбор IoC
    #38474101
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУХватит писать глупости. Чем выше требования, тем больше функционала. То есть обсуждение имеет место для конкретного функционла, я уже об этом писал. Мне вполне устроить мотоцикл, а не самосвал. Мысль понятна?

я тебе не о функционале говорю. ты писал "нативно" а сейчас уже отбрехиваешься от своих слов? не?


МСУтебе решил задачу. Если ты хочешь этот функционал в DI, возьми DI помощнее. Это же не значит, что если в автофаке есть что-то, чего нету в юнити, значит юнити на DI? Тут тоже так. MS наделили DependencyResolver минимальным набором, которого хватает 99% разработчикам. Для чего-то более серьезного - бери самосвал.

чиорт подиери. при чем тут решение задачи. ты говорил в MVC есть DI. я тебя спросил, покажи мне его. ты написал свой, воткнул его и рад стараться. плевать что там, самокат или самосвал. в родном MVC нет ни того, ни дрогого. но есть отличная трасса (читай, поддержка ).
...
Рейтинг: 0 / 0
выбор IoC
    #38474111
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttда очень просто. DI-контейнер инжектирует зависимости через открытый конструктор или через открытые свойства. и он инжектирует все зависимости неограниченно в глубину, иначе смысл в DI теряется напрочь.
А локатор только ищет. Я же тебе объяснил вот тут: 15173084
Но DependencyResolver может иметь:
1. Свои сопоставления через реализацию IDependencyResolver
2. SetResolver
Эти два пункта уже не относятся к сервис локатору. Следовательно, это уже не локатор.

Давай так: это контейнер без возможности инжектировать напрямую (инжектировать будем через фабрику, пусть это будет моя мальенькая хитрось) Тем более эта возможность многим реально не нужна.

hVosttдолжна быть точка регистрации всех зависимостей таким образом, чтобы она происходила снаружи (каждый подключаемый модуль сам регистрирует все свои типы). контейнер ни о каких типах ничего знать не должен.
Эта точка есть, она реализуется в реализации IDependencyResolver. Регистриуется через SetResolver. И доступна для поиска. И всё это может штатный DependencyResolver. Таки совсем не локатор, согласен?

hVosttя незнаю почему ты так снисходительно относишься к Lifetime Scope, но без управления жизненным циклом объектов DI-контейнер что безрукий кастрат.
Не передергивай, я не против управления жизнью. Но только тогда, когда это будет требовать задача. Когда такая задача будет, я возьму это:

Код: c#
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
public interface IUnityContainer : IDisposable
{
        IUnityContainer Parent { get; }
        IEnumerable<ContainerRegistration> Registrations { get; }

        IUnityContainer AddExtension(UnityContainerExtension extension);
        object BuildUp(Type t, object existing, string name, params ResolverOverride[] resolverOverrides);
        object Configure(Type configurationInterface);
        IUnityContainer CreateChildContainer();
        IUnityContainer RegisterInstance(Type t, string name, object instance, LifetimeManager lifetime);
        IUnityContainer RegisterType(Type from, Type to, string name, LifetimeManager lifetimeManager, params InjectionMember[] injectionMembers);
        IUnityContainer RemoveAllExtensions();
        object Resolve(Type t, string name, params ResolverOverride[] resolverOverrides);
        IEnumerable<object> ResolveAll(Type t, params ResolverOverride[] resolverOverrides);
        void Teardown(object o);
}
...
Рейтинг: 0 / 0
выбор IoC
    #38474123
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttМСУА ты смешной :)

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

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

hVosttя тебе не о функционале говорю. ты писал "нативно" а сейчас уже отбрехиваешься от своих слов? не?
Я же сказал, DependencyResolver "нативно" поддерживает 2 фичи. Которые не свойственны локатору впринципе. DependencyResolver - это простой DI контейнер.

hVosttчиорт подиери. при чем тут решение задачи. ты говорил в MVC есть DI.
Да, именно так.

hVosttя тебя спросил, покажи мне его.
Я показал. А ты назвал его локатором. Пришлось немного потрудиться, но мне удалось тебя убедить в том, что это не локатор. Тут согласен, что был не прав?

hVosttты написал свой, воткнул его и рад стараться.
Я написал свой чисто под задачу инъекции в конструктор. Подпорка к штатному контейнеру. Согласен?

hVosttплевать что там, самокат или самосвал. в родном MVC нет ни того, ни дрогого.
Я же тебе рассказал про 2 фичи. Пропустил мимо ушей:
...
Рейтинг: 0 / 0
выбор IoC
    #38474151
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУЯ написал свой чисто под задачу инъекции в конструктор. Подпорка к штатному контейнеру. Согласен?

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

урите же!

Код: c#
1.
2.
3.
public interface IDoAnyJob {
   void DoIt();
}



отдаю даром да, конечно надо свою реализацию сделать. но согласись же, это бомба! любую работу делает!

МСУЯ же сказал, DependencyResolver "нативно" поддерживает 2 фичи. Которые не свойственны локатору впринципе. DependencyResolver - это простой DI контейнер.
МСУНо DependencyResolver может иметь:
1. Свои сопоставления через реализацию IDependencyResolver
2. SetResolver

т.е. это всё DI, осталось только реализовать IDependencyResolver так? а ну да, ещё фабрики свои определить...

представляю, как бы ты с таким подходом продавал дом:
— ...ну вы же говорили у вас есть вода!
— Что вы кранов не видите чтоли? Вон и трубы есть...
— ... ну так оттуда же ничего не течёт!
— Щас погодите, я тут подогнал к дому свой личный водовоз, будет вам демонстрация, что вода есть. А если вам нужна газировка или пиво, можете даже шампанское подключить, будете коня своего купать! надо только свой самосвал подогнать
...
Рейтинг: 0 / 0
выбор IoC
    #38474165
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttя тут как раз изобрёл универсальное средство.
Оно умеет лямбду "транслировать" в Expression? )

МСУЯ же сказал, DependencyResolver "нативно" поддерживает 2 фичи. Которые не свойственны локатору впринципе. DependencyResolver - это простой DI контейнер.
МСУНо DependencyResolver может иметь:
1. Свои сопоставления через реализацию IDependencyResolver
2. SetResolver

hVosttт.е. это всё DI, осталось только реализовать IDependencyResolver так?
Вообще-то это в любом случае нужно сделать. Именно таким образом определяются сопоставления. Их в любом случае нужно делать в любом DI контейнере. В случае DependencyResolver делается именно так, через твоё любимое наследование. Не вижу причин для паники.

hVosttа ну да, ещё фабрики свои определить...
Смотря для чего. В моих проектах они не определены. За ненадобностью.
...
Рейтинг: 0 / 0
выбор IoC
    #38474206
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУДавай так: это контейнер без возможности инжектировать напрямую (инжектировать будем через фабрику, пусть это будет моя мальенькая хитрось) Тем более эта возможность многим реально не нужна.

ну да, это SL-локатор, но такого типа, который легко превращается в DI.


МСУЭта точка есть, она реализуется в реализации IDependencyResolver. Регистриуется через SetResolver. И доступна для поиска. И всё это может штатный DependencyResolver. Таки совсем не локатор, согласен?

совсем не согласен. получается сторонный модуль должен напрямую дёрнуть SetResolver. не хорошо. про какую тогда мы инверсию зависимостей говорим?

МСУНе передергивай, я не против управления жизнью. Но только тогда, когда это будет требовать задача. Когда такая задача будет, я возьму это:

а когда это не требуется?
...
Рейтинг: 0 / 0
выбор IoC
    #38474214
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУОно умеет лямбду "транслировать" в Expression? )

ещё как
...
Рейтинг: 0 / 0
выбор IoC
    #38474223
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУВообще-то это в любом случае нужно сделать. Именно таким образом определяются сопоставления. Их в любом случае нужно делать в любом DI контейнере. В случае DependencyResolver делается именно так, через твоё любимое наследование. Не вижу причин для паники.

не-не-не... если бы можно было выполнить что-то типа DependencyResolver.Current.Register<T>().As<I>() (или вроде того) и получить инверсию зависимостей в контроллерах, то можно было бы утверждать о наличии нативного DI контейнера.

а пока что нет.
...
Рейтинг: 0 / 0
выбор IoC
    #38474249
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttну да, это SL-локатор, но такого типа, который легко превращается в DI.
Ты хоть понимаешь, какую глупость ляпнул?

hVosttсовсем не согласен. получается сторонный модуль должен напрямую дёрнуть SetResolver. не хорошо. про какую тогда мы инверсию зависимостей говорим?
Что за бред, какой сторонний модуль? Это должен сделать тот, кто создал контейнер.

hVosttа когда это не требуется?
Обратный вопрос.
...
Рейтинг: 0 / 0
выбор IoC
    #38474260
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttМСУВообще-то это в любом случае нужно сделать. Именно таким образом определяются сопоставления. Их в любом случае нужно делать в любом DI контейнере. В случае DependencyResolver делается именно так, через твоё любимое наследование. Не вижу причин для паники.

не-не-не... если бы можно было выполнить что-то типа DependencyResolver.Current.Register<T>().As<I>() (или вроде того) и получить инверсию зависимостей в контроллерах, то можно было бы утверждать о наличии нативного DI контейнера.

а пока что нет.
Ты как маленький ребенок. Какая разница, как именно регистрируются зависимости
...
Рейтинг: 0 / 0
выбор IoC
    #38474280
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУОбратный вопрос.

практически всегда. либо объект выдаётся один и тот же в рамках одного httprequest, либо каждый раз создаётся новый, либо один на весь домен, либо один на тред, либо из кеша... либо в рамках жизненной транзакции.

DI также должен разрушить Disposable-объект, когда он будет не нужен.
...
Рейтинг: 0 / 0
выбор IoC
    #38474283
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУТы как маленький ребенок. Какая разница, как именно регистрируются зависимости

не как , а где и когда.
...
Рейтинг: 0 / 0
выбор IoC
    #38474318
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttпрактически всегда. либо объект выдаётся один и тот же в рамках одного httprequest, либо каждый раз создаётся новый, либо один на весь домен, либо один на тред, либо из кеша... либо в рамках жизненной транзакции.
Если говорить о вебе, то меня устраивает дефолтное поведение: на реквест, по окончанию будет диспоуз.

hVosttDI также должен разрушить Disposable-объект, когда он будет не нужен.
Это я сам определю, мне не нужно это от DI.

hVosttМСУТы как маленький ребенок. Какая разница, как именно регистрируются зависимости
не как , а где и когда.
Всегда Цацку не дали - всё, это не DI!
...
Рейтинг: 0 / 0
выбор IoC
    #38474350
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУЕсли говорить о вебе, то меня устраивает дефолтное поведение: на реквест, по окончанию будет диспоуз.

кто диспозит?
...
Рейтинг: 0 / 0
выбор IoC
    #38474443
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttкто диспозит?
В MVC базовый контроллер, как вариант. Может и контроллер наследник, если потребуется какая-то нештатная ситуация.

Код: c#
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
protected override void Dispose(bool disposing)
{
    if (disposing)
    {
        if (_dataService != null)
        {
            _dataService.Dispose();
        }
    }

    base.Dispose(disposing);
}



В том же WPF отдельная абстракция IWindowService (выполняет роль презентёра):

Код: c#
1.
2.
3.
4.
5.
6.
7.
8.
9.
public void OpenEmployeesWindow()
{
    var view = new EmployeesWindow();
    view.Owner = ActiveWindow;
    var vm = new EmployeesViewModel(App.Container); // 
    view.DataContext = vm;
    view.Show();
    view.Closed += (a, b) => { vm.Dispose(); Application.Current.MainWindow.Focus(); };
}



EmployeesViewModel
Код: c#
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
83.
84.
85.
86.
87.
88.
89.
90.
91.
92.
93.
94.
95.
96.
97.
98.
99.
100.
101.
102.
103.
104.
105.
106.
107.
108.
109.
110.
111.
112.
113.
114.
115.
116.
117.
118.
119.
120.
121.
122.
123.
124.
125.
126.
127.
128.
129.
130.
131.
132.
133.
134.
135.
136.
137.
138.
139.
140.
141.
142.
143.
144.
145.
146.
147.
148.
149.
150.
151.
152.
153.
154.
155.
156.
157.
158.
159.
160.
161.
162.
163.
164.
165.
166.
167.
168.
169.
170.
171.
172.
173.
174.
175.
176.
177.
178.
179.
180.
181.
182.
183.
184.
185.
186.
187.
188.
189.
190.
191.
192.
193.
194.
195.
196.
197.
198.
199.
200.
201.
202.
203.
204.
205.
206.
207.
208.
209.
210.
211.
212.
213.
214.
215.
216.
public class EmployeesViewModel : ViewModelBase
{
    private IDataContext Context;
    private IWindowService WinService;

    public EmployeesViewModel(IUnityContainer container)
    {
        Context = container.Resolve<IDataContext>();
        WinService = container.Resolve<IWindowService>();

        Find(string.Empty);
    }

    public override void Dispose()
    {
        Context.Dispose();
    }

    private ObservableCollection<Employee> _employees;
    public ObservableCollection<Employee> Employees
    {
        get
        {
            return _employees;
        }
        set
        {
            _employees = value;
            OnPropertyChanged(() => Employees); 
        }
    }
        
    private string _lastName;
    public string LastName
    {
        get
        {
            return _lastName;
        }
        set
        {
            _lastName = value;
            OnPropertyChanged(() => LastName);                
        }
    }

    private int _totalRows;
    public int TotalRows
    {
        get
        {
            return _totalRows;
        }
        set
        {
            _totalRows = value;
            OnPropertyChanged(() => TotalRows);
        }
    }

    private Employee _currentEmployee;
    public Employee CurrentEmployee
    {
        get
        {
            return _currentEmployee;
        }
        set
        {
            _currentEmployee = value;
            OnPropertyChanged(() => CurrentEmployee);
        }
    }
        
    public void Update(Employee employee)
    {
        var result = WinService.OpenEmployeeDetailWindow(employee ?? new Employee());
        if (result != null)
        {
            if (result.EmployeeId > 0)
            {
                employee.FirstName = result.FirstName;
                employee.LastName = result.LastName;
                employee.Fired = result.Fired;
                employee.Birthday = result.Birthday;
                employee.Stage = result.Stage;
            }
            else
            {
                var employeeNew = Context.UpdateEmployee(result.EmployeeId, result.FirstName, result.LastName, result.Birthday, result.Fired, result.Stage);
                WinService.UpdateDetailWindowAfterCreate(employeeNew);
                TotalRows += 1;
            }
        }
    }

    public void Delete(IEnumerable<Employee> employees)
    {
        if (employees.Any())
        {
            if (WinService.IsOk("Удалить выбранные записи?", "Удаление"))
            {
                int count = employees.Count();
                if (Context.DeleteEmployees(employees))
                {
                    WinService.UpdateDetailWindowAfterDelete(employees);
                    TotalRows -= count;
                }
            }
        }
    }

    public void Find(string lastName)
    {
        var items = Enumerable.Empty<Employee>();

        if (!string.IsNullOrEmpty(LastName))
        {
            items = Context.GetEmployees().Where(d => d.LastName.Contains(lastName));
        }

        Employees = new ObservableCollection<Employee>(items);
        TotalRows = Employees.Count;        
    }

    private ICommand _findCommand;
    public ICommand FindCommand
    {
        get
        {
            if (_findCommand == null)
            {
                _findCommand = new RelayCommand(action => Find(this.LastName));
            }

            return _findCommand;
        }
    }

    private ICommand _updateCommand;
    public ICommand UpdateCommand
    {
        get
        {
            if (_updateCommand == null)
            {
                _updateCommand = new RelayCommand(action =>
                {
                    if (action != null)
                    {
                        Update((Employee)action);
                    }
                }, action => CurrentEmployee != null);
            }

            return _updateCommand;
        }
    }        

    private ICommand _createCommand;
    public ICommand CreateCommand
    {
        get
        {
            if (_createCommand == null)
            {
                _createCommand = new RelayCommand(action => Update(null), action => true);
            }

            return _createCommand;
        }
    }

    private ICommand _deleteCommand;
    public ICommand DeleteCommand
    {
        get
        {
            if (_deleteCommand == null)
            {
                _deleteCommand = new RelayCommand(action => Delete((action as IList).Cast<Employee>()), action => CurrentEmployee != null);
            }

            return _deleteCommand;
        }
    }


    private ICommand _closeCommand;
    public ICommand CloseCommand
    {
        get
        {
            if (_closeCommand == null)
            {
                _closeCommand = new RelayCommand(action => { WinService.CloseActiveWindow(); });
            }

            return _closeCommand;
        }
    }

    private ICommand _excelCommand;
    public ICommand ExcelCommand
    {
        get
        {
            if (_excelCommand == null)
            {
                _excelCommand = new RelayCommand(action => { });
            }

            return _excelCommand;
        }
    }        
}



P.S. Хвост, ты сначала изучи хорошенько ООП и нативные возможности .NET, а то как курица уткнулся во что-то одно и не желаешь смотреть объективнее на жизнь.
...
Рейтинг: 0 / 0
выбор IoC
    #38474453
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Не вставилось, продолжаем тему диспоузинга в XAML технологиях:

Код: c#
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
public partial class App : Application
{
    public static IUnityContainer Container;

    public App()
    {
        string connectionString = "...";

        Container = new UnityContainer();
        Container.RegisterType<IDataContext, DataContext>(new InjectionConstructor(connectionString));
        Container.RegisterType<IWindowService, WindowService>(new ContainerControlledLifetimeManager());
            
        this.Dispatcher.UnhandledException += OnDispatcherUnhandledException;
        EventManager.RegisterClassHandler(typeof(DatePicker), DatePicker.LoadedEvent, new RoutedEventHandler(OnLoaded));
    }
}



Ну и так далее. Хвост, что тебя конкретно интересует? Вчера научил тебя LINQ, даже спасибо не сказал. Сегодня разжевал тебе инверсию. Скоро ты станешь богом, да?
...
Рейтинг: 0 / 0
выбор IoC
    #38474473
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУВ MVC базовый контроллер, как вариант. Может и контроллер наследник, если потребуется какая-то нештатная ситуация.

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

не товарищ. я канеш уверен, что это работает. и что так повсеместно делают. но это хреновая практика. для первокурсника какого ещё сойдёт, ему лишь бы компилелось и запускалось. но для серьезного дядьки, не камильфо так яростно говнокодить. ещё и с умным видом.
...
Рейтинг: 0 / 0
выбор IoC
    #38474479
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУP.S. Хвост, ты сначала изучи хорошенько ООП и нативные возможности .NET

вот я не пойму что ты имеешь в виду под "изучи ООП"? взять одну из классических книжек по ООП, там на 100 листов полезных листа 2, остальное — неумный пеар, как ООП спасёт мир.

даж GoF-паттерны и те в осномном применимы лишь для построение библиотек и фреймворков. для построение архитектуры конечных приложений применяеются композиция, а не наследования. хрен ли там от ООП толку.
...
Рейтинг: 0 / 0
выбор IoC
    #38474494
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУНу и так далее. Хвост, что тебя конкретно интересует? Вчера научил тебя LINQ, даже спасибо не сказал.

ну дык
...
Рейтинг: 0 / 0
выбор IoC
    #38474500
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУВ том же WPF отдельная абстракция IWindowService (выполняет роль презентёра):

ну а нафига? зачем словно сопли по кафелю размазывать ответственность по классам? кто выдал инстанс, тот пусть будет добр его и уничтожит. сам создал? сам и убей.
...
Рейтинг: 0 / 0
выбор IoC
    #38474502
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУВчера научил тебя LINQ, даже спасибо не сказал.

вообче, спасибо
...
Рейтинг: 0 / 0
выбор IoC
    #38474568
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttфигня какая-то. это ж с какого-та перепугу контроллер решил, что может диспозить чужой объект выданный ему внешним компонентом??
Вообще-то, он - контроллер, является миддлом (ака презентёр). В его пропертях в явном виде доступны абстракции, которые были инжектированы (возможно, им же). Кому как не ему знать, когда и что нужно выгрузить. Не говори глупостей. Контроллер - это святыня святых.

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

hVosttвот я не пойму что ты имеешь в виду под "изучи ООП"? взять одну из классических книжек по ООП, там на 100 листов полезных листа 2, остальное — неумный пеар, как ООП спасёт мир.
Ну ты ведь вопишь о том, что наследование УГ и старпёрство. А я тебе говорю, что ты просто еще не силён в этом. Вот я и говорю, что изучи.

hVosttдаж GoF-паттерны и те в осномном применимы лишь для построение библиотек и фреймворков. для построение архитектуры конечных приложений применяеются композиция, а не наследования. хрен ли там от ООП толку .
Бестолочь ты. Прости меня Бог...

Вот тебе пример: обычная с виду базовая вью модель "ака привет мир" (да, я знаю, как ты не любишь наследование с виртуальными методами):
Но тем не менее, смотри, сколько она может: и подчищать хвосты, и нотифицировать, и валидировать. Бери, наследуй и пиши с минимумом кода.

...
Код: c#
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
public class ViewModelBase : IDisposable, IDataErrorInfo, INotifyPropertyChanged
{
    public void OnPropertyChanged(string propname)
    {
        if (PropertyChanged != null)
        {
            PropertyChanged(this, new PropertyChangedEventArgs(propname));
        }
    }

    protected void OnPropertyChanged<T>(Expression<Func<T>> propertyExpression)
    {
        if (propertyExpression.Body.NodeType == ExpressionType.MemberAccess)
        {
            OnPropertyChanged((propertyExpression.Body as MemberExpression).Member.Name);
        }
    }

    public event PropertyChangedEventHandler PropertyChanged;

    public virtual void Dispose()
    {
            
    }

    public virtual string Error
    {
        get { return null; }
    }

    public virtual string this[string columnName]
    {
        get { return null; }
    }
}



Что тут плохого?

hVosttМСУВ том же WPF отдельная абстракция IWindowService (выполняет роль презентёра):
ну а нафига? зачем словно сопли по кафелю размазывать ответственность по классам? кто выдал инстанс, тот пусть будет добр его и уничтожит. сам создал? сам и убей.
Батенька, про разделение ответственности ничего не слыхал? Какие сопли? Часто бывает так, что нужно подчищать хвосты при определенной логике, это будет посложнее простого окончания реквеста. Например, подчистить ссылку при закрытии окна в XAML. Заметь, это не WinForms, окно не реализует никаких IDisposable. Твои действия? :)
...
Рейтинг: 0 / 0
выбор IoC
    #38474570
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУВот тебе пример: обычная с виду базовая вью модель "ака привет мир"...
Только что заметил, что эта модель с Expression<Func<T>> propertyExpression Твоя тема!
...
Рейтинг: 0 / 0
выбор IoC
    #38474593
Фотография Где-то в степи
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
что то вот сижу и не догоняю.
предположим контейнер выдал нам объект, если - наблюдатели не участвуют, подсчет ссылок не ведется, контейнер не привязан ни к одному внешнему событию, сквозной интеграции в код нет то как он знает что объект уже бесхозный и что его можно диспозить?
Спасибо...
...
Рейтинг: 0 / 0
выбор IoC
    #38474602
Фотография Где-то в степи
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
не уж то using ?
...
Рейтинг: 0 / 0
выбор IoC
    #38474605
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Где-то в степичто то вот сижу и не догоняю.
предположим контейнер выдал нам объект, если - наблюдатели не участвуют, подсчет ссылок не ведется, контейнер не привязан ни к одному внешнему событию, сквозной интеграции в код нет то как он знает что объект уже бесхозный и что его можно диспозить?
Спасибо...
Тогда время жизни объекта будет такое же, как и время жизни контейнера. Что-то типа реализации ContainerControlledLifetimeManager от Unity.
...
Рейтинг: 0 / 0
выбор IoC
    #38474619
Фотография Где-то в степи
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУ, ну это не интересно, в принципе ничего тут ништяковского нет, создание контейнера должно быть на раз и легкое, хочся
ПРОСТО писать код, а о зачистке пускай заботится контейнер ( так сказать дублирование функции коллектора)
...
Рейтинг: 0 / 0
выбор IoC
    #38474625
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Где-то в степиМСУ, ну это не интересно, в принципе ничего тут ништяковского нет, создание контейнера должно быть на раз и легкое, хочся
ПРОСТО писать код, а о зачистке пускай заботится контейнер ( так сказать дублирование функции коллектора)
Я выше озвучил задачу на XAML. Как контейнер должен угадать, что закрывается такое-то Window и что нужно подчистить такие-то объекты?
...
Рейтинг: 0 / 0
выбор IoC
    #38474632
Фотография Где-то в степи
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУ, Я это видел - спасибо, но оппонент вроде отвергает это ( скорее не отвергает, а говорит что есть лучше фишка) , и имеет свою точку зрения, вот с его точки зрения я и рассуждаю, твой код раннее просмотрел ( целых два раза)
...
Рейтинг: 0 / 0
выбор IoC
    #38474636
Фотография Где-то в степи
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
автор кто выдал инстанс, тот пусть будет добр его и уничтожит. сам создал? сам и убей.
...
Рейтинг: 0 / 0
выбор IoC
    #38474644
Фотография Где-то в степи
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУ,
я бы мог согласиться что
Код: c#
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
 public T Resolve<T>()
        {
            var o = Activator.CreateInstance<T>();
            try
            {
                return o;
            }
            finally
            {
                var disposable = o as IDisposable; 
                if(disposable != null)
                    disposable.Dispose();
            }
        }


но это же банальщина рвет весь формат дискусии..
...
Рейтинг: 0 / 0
выбор IoC
    #38474657
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Где-то в степиМСУ, Я это видел - спасибо, но оппонент вроде отвергает это ( скорее не отвергает, а говорит что есть лучше фишка) , и имеет свою точку зрения, вот с его точки зрения я и рассуждаю, твой код раннее просмотрел ( целых два раза)
Оппонент и вчера отвергал информацию о том, что лямбда компилируется в делегат. Пока по зубам ему не настучали... :)
...
Рейтинг: 0 / 0
выбор IoC
    #38474691
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Где-то в степи, в общем варианте MVVM решение такое (хвосту не читать, который меряет жизнь одним шаблоном):

Вот вью модель. После инжектирования в неё DI контейнера, она резолвит нужный объект, использует его и уничтожает. Всё.
В следующий раз контейнер опять отдаст новый экземпляр. Диспоузить по требованию очень важно - например ситуации с веб сервисами, жизнь инстанса сервиса должна быть как можно короче. Попользовал пару методов и грохнул опосля. Ни один контйнер не сможет угадать тот момент времени, когда нужен Dispose. Я и только я знаю этот момент.

Код:

Код: c#
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
public class EmployeeViewModel : ViewModelBase
{
    private IUnityContainer Container;

    public EmployeeViewModel(IUnityContainer container)
    {
        this.Container = container;

        var ctx = Container.Resolve<IDataContext>();
        var stages = ctx.GetEmployeeStages();
        // Тот, кто резолвит - уничтожает!
        ctx.Dispose();

        Stages = new ObservableCollection<EmployeeStage>(stages);
    }

    public int EmployeeId { get; set; }

    public string FirstName { get; set; }

    private ObservableCollection<EmployeeStage> _stages;
    public ObservableCollection<EmployeeStage> Stages
    {
        get
        {
            return _stages;
        }
        set
        {
            _stages = value;
            OnPropertyChanged(() => Stages);
        }
    }
}
...
Рейтинг: 0 / 0
выбор IoC
    #38474713
Фотография Где-то в степи
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУ, мне казалось. что хвост имеет глобальный.
да бог с этим, контейнеры - банальный код ( как квадрат малевича ) но в то же время можно говорить о них годами, ибо разные исполнения обросли разными вкусняшками, можно как Чапай ( В.И.) - написать свой..
пожалуй соглашусь, что "временем жизни" должен управлять кто заказал инстанс, а не кто его смастерил,
...
Рейтинг: 0 / 0
выбор IoC
    #38474720
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Где-то в степида бог с этим, контейнеры - банальный код ( как квадрат малевича ) но в то же время можно говорить о них годами, ибо разные исполнения обросли разными вкусняшками, можно как Чапай ( В.И.) - написать свой..
О чем и речь. Но он замахивается на наследование, на ООП. Говорит, что это УГ и старпёрство. Каким нужно быть близоруким прыщавым студнем, что бы писать такие вещи? :)

Где-то в степипожалуй соглашусь, что "временем жизни" должен управлять кто заказал инстанс, а не кто его смастерил,
+1К, только попробуй это объяснить студенту, который мыслит одним шаблоном, вброшенным в букварь, который он сейчас читает... Это всё от неопытности. Ничего, я сделаю из него человека Но уж много энергии уходит на этого мальчёнку, однако. Давишь его, как прыщ, а он уворачивается и вскакивает в другом месте. Давишь там - он опять прыгает как заяц. Пока не выдавишь, не успокоится.
...
Рейтинг: 0 / 0
выбор IoC
    #38474727
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Так и по сабжу, доипался студень до мвц-шного DependencyResolver, мол инжектить не умеет Объяснил на пальцах, как можно пукалку сделать. Начал горланить, мол этот функционал должен быть вшит в DI конейнер. Оскорбил замечательный DependencyResolver сервис локатором. Объяснил на пальцах, что помимо локаторности, DependencyResolver обладает еще двумя фишками - может описывать зависимости и регистрировать их. Далее, начал он орать, что мол нету управлением жизни. Объясняю на пальцах, что DependencyResolver - это простенький контейнер, без наворотов. Что-то типа легковесного SimpleIoC . Не доходит... Потом начал гнать на ООП, это вообще песня. Потом понесло его ветром в сторону того, кто и как должен диспоузить. Вообщем, цирк
...
Рейтинг: 0 / 0
выбор IoC
    #38474822
Фотография Где-то в степи
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУ, ох и любишь ты потоптаться на костях, ничо страшного не знает - научится, учись посыпать голову пеплом - это то же в жиpни
будет пригождаться :)
...
Рейтинг: 0 / 0
выбор IoC
    #38474944
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Где-то в степиМСУ, ох и любишь ты потоптаться на костях
Топтаться не цепляет, а вот станцевать твист на костях подопытных кодеманок - вот оно че, Михалыч
...
Рейтинг: 0 / 0
выбор IoC
    #38475088
SeVa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУГде-то в степи, в общем варианте MVVM решение такое (хвосту не читать, который меряет жизнь одним шаблоном):

Вот вью модель. После инжектирования в неё DI контейнера, она резолвит нужный объект, использует его и уничтожает. Всё.
В следующий раз контейнер опять отдаст новый экземпляр. Диспоузить по требованию очень важно - например ситуации с веб сервисами, жизнь инстанса сервиса должна быть как можно короче. Попользовал пару методов и грохнул опосля. Ни один контйнер не сможет угадать тот момент времени, когда нужен Dispose. Я и только я знаю этот момент.

Код:

Код: c#
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
public class EmployeeViewModel : ViewModelBase
{
    private IUnityContainer Container;

    public EmployeeViewModel(IUnityContainer container)
    {
        this.Container = container;

        var ctx = Container.Resolve<IDataContext>();
        var stages = ctx.GetEmployeeStages();
        // Тот, кто резолвит - уничтожает!
        ctx.Dispose();

        Stages = new ObservableCollection<EmployeeStage>(stages);
    }

    public int EmployeeId { get; set; }

    public string FirstName { get; set; }

    private ObservableCollection<EmployeeStage> _stages;
    public ObservableCollection<EmployeeStage> Stages
    {
        get
        {
            return _stages;
        }
        set
        {
            _stages = value;
            OnPropertyChanged(() => Stages);
        }
    }
}



Ой, дорогая редакция, Муслима за контейнеры взялся!!! Дитятко растет на глазах.
Dispose в конструкторе порадовал, не успели создать и тут же прибиваем. Наверное, viewmodel очень секретные у тебя и перед прочтением нужно сжечь.
Начинающий архитектор, будешь под каждый viewmodel отдельный контейнер заводить?


ЗЫ Тупица, правильно сказали, что DependencyResolver - CommonLocator. Ты как всегда и в теплом, и мягком с головы до пят
...
Рейтинг: 0 / 0
выбор IoC
    #38475157
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ух ты кто пожаловал сюда, не уж-то фееричная сильверлайтная обезьяна без ума и фантазии?
Шагом марш читать букварь, чем тебя так напугал диспоуз сервиса в ctor вью модели? Хотя чего это я, дальше хеллоуворлдных пукалок на тухлом призме у тебя нет и не было. Впрочем это и так видно невооруженным глазом, когда читаешь твой высер про вью модель и контейнер. Откуда знаешь про контейнеры, нагуглил? Вообщем, джуниор девелопер, рано тебе еще тут гадить, иди лучше детвора расскажи про генерацию сборок в памяти. Пусть посмеются над идиотом.
...
Рейтинг: 0 / 0
выбор IoC
    #38475167
SeVa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУУх ты кто пожаловал сюда, не уж-то фееричная сильверлайтная обезьяна без ума и фантазии?
Шагом марш читать букварь, чем тебя так напугал диспоуз сервиса в ctor вью модели? Хотя чего это я, дальше хеллоуворлдных пукалок на тухлом призме у тебя нет и не было. Впрочем это и так видно невооруженным глазом, когда читаешь твой высер про вью модель и контейнер. Откуда знаешь про контейнеры, нагуглил? Вообщем, джуниор девелопер, рано тебе еще тут гадить, иди лучше детвора расскажи про генерацию сборок в памяти. Пусть посмеются над идиотом.

Муслимка, ты все время обходился правой рукой, а теперь резиновой куклой. Ты сначала пройди курс молодого бойца, чтобы понимать хотя бы с какого бока к ней пристраиваться, а уж потом разглагольствуй.



ЗЫ Модераторы, долго это чмо будет пачкать своей дурью мозги другим? То, что он несет на форуме - полный бред.
...
Рейтинг: 0 / 0
выбор IoC
    #38475170
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SeVaМуслимка, ты все время обходился правой рукой, а теперь резиновой куклой. Ты сначала пройди курс молодого бойца, чтобы понимать хотя бы с какого бока к ней пристраиваться, а уж потом разглагольствуй.
Долбосевка, ты всё время обходился пустой полостью в черепе, а теперь заимел мозг? Ты сначала нагенери мне мембершипных сборок в памяти, клоун недоделаный, а потом мы с тобой поговорим о курсе молодого бойца.

SeVaЗЫ Модераторы, долго это чмо будет пачкать своей дурью мозги другим? То, что он несет на форуме - полный бред.
Что за детский плач в зеркало?

...
Рейтинг: 0 / 0
выбор IoC
    #38475191
SeVa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Позор российского программирования, от индуски после 2х месячных курсов будет меньше урона, чем от тебя.
Контейнеры требуют совсем другого подхода к проектированию и разработке. Другие подходы, в свою очередь, требуют времени на освоение и практики в реальных проектах. Чтобы в этом убедиться достаточно посмотреть на твои жалкие потуги с wpf. После таскания контролов будут только одни говносервисы, которыми ты начал пачкать и этот форум.
Я больше, чем уверен, что ты даже не заглянул на сайт unity, не прочитал букварь, и не посмотрел примеры из курса молодого бойца, но уже взялся бойко вякать.
Если бы в руках у мартышки, которую ты запостил выше, была бы граната с надписью "i'e love unity", то осталось бы только сделать надпись "Осторожно!!! МсУ изучает unity".
...
Рейтинг: 0 / 0
выбор IoC
    #38475225
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Долбосева - счастье российского программирования, индусы обтекают от зависти. Куда не вляпается этот утырок - везде красота и мощ прикладного кода. Правда, как выяснилось, это обычный сон. На самом деле долбосявка - классическая унылая обезьяна с завышенным ЧСВ и потными ладошками.
Контейнеры? Что ты о них знаешь? О каком программировании может рассуждать клиническая истеричка, которая генерит сборки в памяти? Цирк!
...
Рейтинг: 0 / 0
выбор IoC
    #38475262
Фотография Изопропил
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
топикстартера интересовала производительность при получении объектов из контнейнера,не?
...
Рейтинг: 0 / 0
выбор IoC
    #38475286
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУВообще-то, он - контроллер, является миддлом (ака презентёр). В его пропертях в явном виде доступны абстракции, которые были инжектированы (возможно, им же). Кому как не ему знать, когда и что нужно выгрузить. Не говори глупостей. Контроллер - это святыня святых.

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

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

МСУА я тебе говорю, что ты просто еще не силён в этом. Вот я и говорю, что изучи.

в чем?

МСУВот тебе пример: обычная с виду базовая вью модель "ака привет мир" (да, я знаю, как ты не любишь наследование с виртуальными методами):
Но тем не менее, смотри, сколько она может: и подчищать хвосты, и нотифицировать, и валидировать. Бери, наследуй и пиши с минимумом кода.
МСУЧто тут плохого?

в данном случае всё ок. такой вариант использования и был предусмотрен. тоже самое на счёт контроллеров. а вот создание ещё одного базового класса 2-ого уровня — уже конкретно пахнет говнокодом.

МСУБатенька, про разделение ответственности ничего не слыхал? Какие сопли? Часто бывает так, что нужно подчищать хвосты при определенной логике, это будет посложнее простого окончания реквеста. Например, подчистить ссылку при закрытии окна в XAML. Заметь, это не WinForms, окно не реализует никаких IDisposable. Твои действия? :)

если бы ты умел пользоваться DI, таких дичайше глупых вопросов бы не задавал.
...
Рейтинг: 0 / 0
выбор IoC
    #38475287
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУЯ выше озвучил задачу на XAML. Как контейнер должен угадать, что закрывается такое-то Window и что нужно подчистить такие-то объекты?

ппц. не вижу смысла в дискуссии, если ты не знаешь как элементарные задачи решаются. продолжай пользоваться нубским using-ом, если не хочешь дальше азов продвинуться. я так умею признавать свои ошибки, и учиться на них. умеешь ли ты?
...
Рейтинг: 0 / 0
выбор IoC
    #38475290
SeVa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Изопропилтопикстартера интересовала производительность при получении объектов из контнейнера,не?
МСУДолбосева - счастье российского программирования, индусы обтекают от зависти. Куда не вляпается этот утырок - везде красота и мощ прикладного кода. Правда, как выяснилось, это обычный сон. На самом деле долбосявка - классическая унылая обезьяна с завышенным ЧСВ и потными ладошками.
Контейнеры? Что ты о них знаешь? О каком программировании может рассуждать клиническая истеричка, которая генерит сборки в памяти? Цирк!

Муслими, это ты кроме своего говнокода ничего не видел, а посему завышенная самооценка и ноль знаний.
Если посмотреть код DependencyResolver, который ты по своей обычной безграмотности обозвал контейнером, а потом с ослиным упорством пачка мозги на пяти страницах, то сразу всем будет понятно, что ты ишак
Код: c#
1.
 public void InnerSetResolver(object commonServiceLocator)


Нормальный фреймворк должен не зависеть от контейнеров и достигается это с помощью servicelocator.
В mvc можно зарегистрировать внешний или использовать две готовые реализации с куцыми возможностями, которые по своим возможностям и близко не стояли рядом с нормальными ioc контейнерами.
Посему можно делать однозначный вывод: ты не знаешь mvc и никогда не нюхал контейнеры, одна только вонь на форумах с говносервисами.
...
Рейтинг: 0 / 0
выбор IoC
    #38475298
Фотография Изопропил
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttещё раз, кто выдаёт экземпляры, тот их и уничтожает. это закон. и лишняя демагогия здесь ни к чему.
жги дальше
...
Рейтинг: 0 / 0
выбор IoC
    #38475301
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ИзопропилhVosttещё раз, кто выдаёт экземпляры, тот их и уничтожает. это закон. и лишняя демагогия здесь ни к чему.
жги дальше

только с вашего позваления
...
Рейтинг: 0 / 0
выбор IoC
    #38475302
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Изопропилтопикстартера интересовала производительность при получении объектов из контнейнера,не?

перечитайте внимательно вопрос топикастера. зачем эти домыслы?
...
Рейтинг: 0 / 0
выбор IoC
    #38475305
Фотография Изопропил
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttперечитайте внимательно вопрос топикастера. зачем эти домыслы?
прочитай хотя бы невнимательно, по ссылке сходи
...
Рейтинг: 0 / 0
выбор IoC
    #38475307
SeVa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Изопропилтопикстартера интересовала производительность при получении объектов из контнейнера,не?

Прежде всего интересуют возможности и как они соответствуют задачам, а уж потом быстродействие.
На клиенте разница в милисекунды никого не интересует, здесь только вкусовые предпочтения.
Сами по себе они редко применяются(MCУ нашел единственное место куда его можно влепить - в конструктор) и важно как они стыкуются с фреймворками. Где-то в степи сформулировал свое, в терминах di : Есть ли поддержка per request? В mvc 4 она появилась, тк они взяли передрали wcf web api, который проектировал архитектор mef. В unity 3 такое время жизни тоже ввели, плюс возможность явно диспозить объекты(а то в случае с mvc 3 много было шума на эту тему).

Серверная часть(например, WCF) - совсем другое кино.
...
Рейтинг: 0 / 0
выбор IoC
    #38475321
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SeVaМуслими, это ты кроме своего говнокода ничего не видел, а посему завышенная самооценка и ноль знаний.
Это слова истерички, которая генерирует сборку прямо в памяти, которая говорит, что IPrincipal круче мембершипа? Я плакал.

SeVaЕсли посмотреть код DependencyResolver, который ты по своей обычной безграмотности обозвал контейнером, а потом с ослиным упорством пачка мозги на пяти страницах, то сразу всем будет понятно, что ты ишак
Если посмотреть возможности DependencyResolver, то обнаружишь своим тупорылым мозгом еще дополнительные возможности, которым не обладает локатор. Отсюда можно сделать вывод, что ты кретин.

SeVaНормальный фреймворк должен не зависеть от контейнеров и достигается это с помощью servicelocator.
Бестолочь, нормальный фреймворк предоставляет возможность определять зависимости прямо не отходя от кассы. Как это сделано в MVC.

SeVaВ mvc можно зарегистрировать внешний или использовать две готовые реализации с куцыми возможностями, которые по своим возможностям и близко не стояли рядом с нормальными ioc контейнерами.
Ты упоротая обезьяна. В MVC DependencyResolver может регистрировать любой сторонний DI, в том числе и Unity

http://www.asp.net/mvc/tutorials/hands-on-labs/aspnet-mvc-4-dependency-injection
Код: c#
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
public class UnityDependencyResolver : IDependencyResolver
     {
          private IUnityContainer container;

          private IDependencyResolver resolver;

          public UnityDependencyResolver(IUnityContainer container, IDependencyResolver resolver)
          {
                this.container = container;
                this.resolver = resolver;
          }

          public object GetService(Type serviceType)
          {
                try
                {
                     return this.container.Resolve(serviceType);
                }
                catch
                {
                     return this.resolver.GetService(serviceType);
                }
          }

          public IEnumerable<object> GetServices(Type serviceType)
          {
                try
                {
                     return this.container.ResolveAll(serviceType);
                }
                catch
                {
                     return this.resolver.GetServices(serviceType);
                }
          }
     }




SeVaПосему можно делать однозначный вывод: ты не знаешь mvc и никогда не нюхал контейнеры, одна только вонь на форумах с говносервисами.
Ты как был бездарностью, так ей и остался.
...
Рейтинг: 0 / 0
выбор IoC
    #38475323
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttМСУЯ выше озвучил задачу на XAML. Как контейнер должен угадать, что закрывается такое-то Window и что нужно подчистить такие-то объекты?
ппц. не вижу смысла в дискуссии, если ты не знаешь как элементарные задачи решаются. продолжай пользоваться нубским using-ом, если не хочешь дальше азов продвинуться. я так умею признавать свои ошибки, и учиться на них. умеешь ли ты?
Я плакал... Тебе был задан вопрос, а ты так подло съехал с ответа. Не стыдно ли тебе? Если еще осталась в тебе искра порядочного собеседника (не такого, как упоротый Долбосева, с дыркой в башке от снаряда), то я жду ответа.

hVosttещё раз, кто выдаёт экземпляры, тот их и уничтожает. это закон. и лишняя демагогия здесь ни к чему.
Глупость несусветная. Я тебе привел элементарную задачу, где это не работает. Ты не стал её решать, а тупо съехал.
...
Рейтинг: 0 / 0
выбор IoC
    #38475357
SeVa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУSeVaМуслими, это ты кроме своего говнокода ничего не видел, а посему завышенная самооценка и ноль знаний.
Это слова истерички, которая генерирует сборку прямо в памяти, которая говорит, что IPrincipal круче мембершипа? Я плакал.

SeVaЕсли посмотреть код DependencyResolver, который ты по своей обычной безграмотности обозвал контейнером, а потом с ослиным упорством пачка мозги на пяти страницах, то сразу всем будет понятно, что ты ишак
Если посмотреть возможности DependencyResolver, то обнаружишь своим тупорылым мозгом еще дополнительные возможности, которым не обладает локатор. Отсюда можно сделать вывод, что ты кретин.

SeVaНормальный фреймворк должен не зависеть от контейнеров и достигается это с помощью servicelocator.
Бестолочь, нормальный фреймворк предоставляет возможность определять зависимости прямо не отходя от кассы. Как это сделано в MVC.

SeVaВ mvc можно зарегистрировать внешний или использовать две готовые реализации с куцыми возможностями, которые по своим возможностям и близко не стояли рядом с нормальными ioc контейнерами.
Ты упоротая обезьяна. В MVC DependencyResolver может регистрировать любой сторонний DI, в том числе и Unity

http://www.asp.net/mvc/tutorials/hands-on-labs/aspnet-mvc-4-dependency-injection
Код: c#
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
public class UnityDependencyResolver : IDependencyResolver
     {
          private IUnityContainer container;

          private IDependencyResolver resolver;

          public UnityDependencyResolver(IUnityContainer container, IDependencyResolver resolver)
          {
                this.container = container;
                this.resolver = resolver;
          }

          public object GetService(Type serviceType)
          {
                try
                {
                     return this.container.Resolve(serviceType);
                }
                catch
                {
                     return this.resolver.GetService(serviceType);
                }
          }

          public IEnumerable<object> GetServices(Type serviceType)
          {
                try
                {
                     return this.container.ResolveAll(serviceType);
                }
                catch
                {
                     return this.resolver.GetServices(serviceType);
                }
          }
     }





SeVaПосему можно делать однозначный вывод: ты не знаешь mvc и никогда не нюхал контейнеры, одна только вонь на форумах с говносервисами.
Ты как был бездарностью, так ей и остался.

И какие же это дополнительные возможности, чмо?
Единственное, чем отличается DependencyResolver от ServiceLocator'а - это обработка ситуации, когда невозможно создать объект. Первый возращает null, а второй exception.
А так, что называется, найдите отличия

Совершенно одинаковые интерфейсы.
Реализации для unity практически не отличаются.
Код: c#
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
using System;
using System.Collections.Generic;
using Microsoft.Practices.ServiceLocation;

namespace Microsoft.Practices.Unity.ServiceLocatorAdapter
{
    public class UnityServiceLocator : ServiceLocatorImplBase
    {
        private IUnityContainer container;

        public UnityServiceLocator(IUnityContainer container)
        {
            this.container = container;
        }

        /// <summary>
        ///             When implemented by inheriting classes, this method will do the actual work of resolving
        ///             the requested service instance.
        /// </summary>
        /// <param name="serviceType">Type of instance requested.</param>
        /// <param name="key">Name of registered service you want. May be null.</param>
        /// <returns>
        /// The requested service instance.
        /// </returns>
        protected override object DoGetInstance(Type serviceType, string key)
        {
            return container.Resolve(serviceType, key);
        }

        /// <summary>
        ///             When implemented by inheriting classes, this method will do the actual work of
        ///             resolving all the requested service instances.
        /// </summary>
        /// <param name="serviceType">Type of service requested.</param>
        /// <returns>
        /// Sequence of service instance objects.
        /// </returns>
        protected override IEnumerable<object> DoGetAllInstances(Type serviceType)
        {
            return container.ResolveAll(serviceType);
        }
    }
}



Что еще нужно, чтобы до тебя дошло, что ты тупорылое чмо, которое ничего не знает?
...
Рейтинг: 0 / 0
выбор IoC
    #38475358
SeVa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
А так, что называется, найдите отличия

ЗЫ Куда-то ссылка подевалась.
...
Рейтинг: 0 / 0
выбор IoC
    #38475364
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SeVaИ какие же это дополнительные возможности, чмо?
Ты настолько тупорылая кухарка, что разучилась читать? Для особо одаренных обезьянок повторяю: 15173323

SeVaЕдинственное, чем отличается DependencyResolver от ServiceLocator'а - это обработка ситуации, когда невозможно создать объект. Первый возращает null, а второй exception.
Тупица, самое главное, он лично сам может определять через SetResolver иной DI. Так же он может сопоставлять. Это далеко не задача локатора.

SeVaА так, что называется, найдите отличия
Дурилко картонное, зачем ты бездумно постишь этот гавнокод? Выпей яду.

SeVaЧто еще нужно, чтобы до тебя дошло, что ты тупорылое чмо, которое ничего не знает?
Сам по себе DependencyResolver - это простой контейнер без наворотов. Тебе этого не понять из-за тупости, которая свойственна таким дегенератам вроде тебя.
...
Рейтинг: 0 / 0
выбор IoC
    #38475365
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SeVa А так, что называется, найдите отличия
ЗЫ Куда-то ссылка подевалась.
Чепушилко, локатор только ищет - это вся его задача. DependencyResolver в MVC - это реальный DI контейнер.
...
Рейтинг: 0 / 0
выбор IoC
    #38475377
SeVa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУSeVaИ какие же это дополнительные возможности, чмо?
Ты настолько тупорылая кухарка, что разучилась читать? Для особо одаренных обезьянок повторяю: 15173323

SeVaЕдинственное, чем отличается DependencyResolver от ServiceLocator'а - это обработка ситуации, когда невозможно создать объект. Первый возращает null, а второй exception.
Тупица, самое главное, он лично сам может определять через SetResolver иной DI. Так же он может сопоставлять. Это далеко не задача локатора.


Тупое чмо, тебе бы помолчать, а ты продолжаешь елозить в своем теплом
Код: c#
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
/// <summary>
    /// This class provides the ambient container for this application. If your
    /// framework defines such an ambient container, use ServiceLocator.Current
    /// to get it.
    /// </summary>
    public static class ServiceLocator
    {
        private static ServiceLocatorProvider currentProvider;

        /// <summary>
        /// The current ambient container.
        /// </summary>
        public static IServiceLocator Current
        {
            get { return currentProvider(); }
        }

        /// <summary>
        /// Set the delegate that is used to retrieve the current container.
        /// </summary>
        /// <param name="newProvider">Delegate that, when called, will return
        /// the current ambient container.</param>
        public static void SetLocatorProvider(ServiceLocatorProvider newProvider)
        {
            currentProvider = newProvider;
        }
    }
}



Ссылка на исходник
...
Рейтинг: 0 / 0
выбор IoC
    #38475378
SeVa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Перечитал еще раз внимательней твое очередной перл
автор он лично сам может определять через SetResolver иной DI


Полный маразм.
Пишу специально медленно(ты туго всасываешь, чтобы до тебя дошло, когда будешь читать по буквам),
ты полный урод.
...
Рейтинг: 0 / 0
выбор IoC
    #38475395
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SeVaТупое чмо, тебе бы помолчать, а ты продолжаешь елозить в своем теплом
Код: c#
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
/// <summary>
    /// This class provides the ambient container for this application. If your
    /// framework defines such an ambient container, use ServiceLocator.Current
    /// to get it.
    /// </summary>
    public static class ServiceLocator
    {
        private static ServiceLocatorProvider currentProvider;

        /// <summary>
        /// The current ambient container.
        /// </summary>
        public static IServiceLocator Current
        {
            get { return currentProvider(); }
        }

        /// <summary>
        /// Set the delegate that is used to retrieve the current container.
        /// </summary>
        /// <param name="newProvider">Delegate that, when called, will return
        /// the current ambient container.</param>
        public static void SetLocatorProvider(ServiceLocatorProvider newProvider)
        {
            currentProvider = newProvider;
        }
    }
}



Ссылка на исходник

Убогое дерьмо,

http://msdn.microsoft.com/en-us/library/ff648968.aspx Шаблон Service Locator не описывает, как создать экземпляр службы . В нем описывается способ регистрации услуг и найти их. Как правило, шаблон поиска сервиса сочетается с фабричной модели и / или модель внедрения зависимостей. Эта комбинация позволяет Service Locator для создания экземпляров услуг.

А теперь смотри сюда, кретин недоделаный:

Код: c#
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
public class DummyDependencyResolver : System.Web.Mvc.IDependencyResolver
{
    public object GetService(Type serviceType)
    {
        if (serviceType.Equals(typeof(IDataService)))
        {
            return new SqlDataService();
        }
        return null;
    }

    public IEnumerable<object> GetServices(Type serviceType)
    { 
        return Enumerable.Empty<object>();
    }
}
...
Рейтинг: 0 / 0
выбор IoC
    #38475396
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SeVaПеречитал еще раз внимательней твое очередной перл
автор он лично сам может определять через SetResolver иной DI


Полный маразм.
Пишу специально медленно(ты туго всасываешь, чтобы до тебя дошло, когда будешь читать по буквам),
ты полный урод.
...
Рейтинг: 0 / 0
выбор IoC
    #38475397
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SeVaПеречитал еще раз внимательней твое очередной перл
автор он лично сам может определять через SetResolver иной DI


Полный маразм.
Пишу специально медленно(ты туго всасываешь, чтобы до тебя дошло, когда будешь читать по буквам),
ты полный урод.
Полный маразм у тебя в тупоголовой черепной коробке.

http://msdn.microsoft.com/ru-ru/library/gg416564(v=vs.108).aspx Предоставляет пункт регистрации для сопоставителей зависимостей, применяя предоставленный локатор общей службы, если используется интерфейс локатора службы.
...
Рейтинг: 0 / 0
выбор IoC
    #38475410
SeVa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУSeVaТупое чмо, тебе бы помолчать, а ты продолжаешь елозить в своем теплом
Код: c#
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
/// <summary>
    /// This class provides the ambient container for this application. If your
    /// framework defines such an ambient container, use ServiceLocator.Current
    /// to get it.
    /// </summary>
    public static class ServiceLocator
    {
        private static ServiceLocatorProvider currentProvider;

        /// <summary>
        /// The current ambient container.
        /// </summary>
        public static IServiceLocator Current
        {
            get { return currentProvider(); }
        }

        /// <summary>
        /// Set the delegate that is used to retrieve the current container.
        /// </summary>
        /// <param name="newProvider">Delegate that, when called, will return
        /// the current ambient container.</param>
        public static void SetLocatorProvider(ServiceLocatorProvider newProvider)
        {
            currentProvider = newProvider;
        }
    }
}




Ссылка на исходник

Убогое дерьмо,

http://msdn.microsoft.com/en-us/library/ff648968.aspx Шаблон Service Locator не описывает, как создать экземпляр службы . В нем описывается способ регистрации услуг и найти их. Как правило, шаблон поиска сервиса сочетается с фабричной модели и / или модель внедрения зависимостей. Эта комбинация позволяет Service Locator для создания экземпляров услуг.

А теперь смотри сюда, кретин недоделаный:

Код: c#
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
public class DummyDependencyResolver : System.Web.Mvc.IDependencyResolver
{
    public object GetService(Type serviceType)
    {
        if (serviceType.Equals(typeof(IDataService)))
        {
            return new SqlDataService();
        }
        return null;
    }

    public IEnumerable<object> GetServices(Type serviceType)
    { 
        return Enumerable.Empty<object>();
    }
}



Муслима, я не врач псих больницы, чтобы понимать твой бред.
Что ты этой половой хотел сказать?
Я вижу только один из возможных вариантов провайдера для локатора и очередное подтверждение тому, что ты опять обосрался и в mvc нет ни какого di контейнера.

ЗЫЫ А то, что в mvc локатор обладает искусственным интеллектом и сам что-то может, обязательно занеси в аналы своего говносборника.
...
Рейтинг: 0 / 0
выбор IoC
    #38475411
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SeVaМуслима, я не врач псих больницы, чтобы понимать твой бред.
Долбосева, ты постоянный пациент псих больницы, тебе не понять возможности DependencyResolver в MVC. Лучше уж генери сборки в памяти в своей палате и не отвлекай никого своей дуростью.

SeVaЧто ты этой половой хотел сказать?
Что ты бестолочь.

SeVaЯ вижу только один из возможных вариантов провайдера для локатора и очередное подтверждение тому, что ты опять обосрался и в mvc нет ни какого di контейнера.
Ты видишь лишь то, что навязывает тебе твоё больное воображение. Прими пилюлю.

SeVaЗЫЫ А то, что в mvc локатор обладает искусственным интеллектом и сам что-то может, обязательно занеси в аналы своего говносборника.
Я скоро там начну писать про твои опусы, чтобы страна знала своих героев идиотов. В MVC в коробке есть всё, что нужно для IoC, в отличие от XAML.
...
Рейтинг: 0 / 0
выбор IoC
    #38475414
SeVa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Перечитал еще раз твою хрень,вернее, надпись на заборе в одной из помоек, где ты привык ошиватьсяавторВ нем описывается способ регистрации услуг и найти их.

Что это за бред? Моя твоя не понимай.

msdnDependency injection containers, often referred to as just "containers," are used to satisfy dependencies between components; satisfying these dependencies typically involves registration and resolution. The Composite Application Library provides support for the Unity Application Block (Unity) container, but it is not container-specific. Because the library accesses the container through the IServiceLocator interface, the container can be replaced. To do this, your container must implement the IServiceLocator interface. Usually, if you are replacing the container, you will also need to provide your own container-specific bootstrapper. The IServiceLocator interface is defined in the Common Service Locator Library. This is an open source effort to provide an abstraction over IoC (Inversion of Control) containers, such as dependency injection containers, and service locators. The objective of using this library is to leverage IoC and Service Location without tying to a specific implementation.
...
Рейтинг: 0 / 0
выбор IoC
    #38475415
SeVa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУSeVaМуслима, я не врач псих больницы, чтобы понимать твой бред.
Долбосева, ты постоянный пациент псих больницы, тебе не понять возможности DependencyResolver в MVC. Лучше уж генери сборки в памяти в своей палате и не отвлекай никого своей дуростью.

SeVaЧто ты этой половой хотел сказать?
Что ты бестолочь.

SeVaЯ вижу только один из возможных вариантов провайдера для локатора и очередное подтверждение тому, что ты опять обосрался и в mvc нет ни какого di контейнера.
Ты видишь лишь то, что навязывает тебе твоё больное воображение. Прими пилюлю.

SeVaЗЫЫ А то, что в mvc локатор обладает искусственным интеллектом и сам что-то может, обязательно занеси в аналы своего говносборника.
Я скоро там начну писать про твои опусы, чтобы страна знала своих героев идиотов. В MVC в коробке есть всё, что нужно для IoC, в отличие от XAML.


Чмо, а по делу что-то можешь сказать? Ты как та мартышка, когда ей наступят на хвост, начинает истошно орать и бросаться шкурками от банана в виде картинок.
На большее не способен, урод от программирования?
...
Рейтинг: 0 / 0
выбор IoC
    #38475416
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУЯ плакал... Тебе был задан вопрос, а ты так подло съехал с ответа. Не стыдно ли тебе? Если еще осталась в тебе искра порядочного собеседника (не такого, как упоротый Долбосева, с дыркой в башке от снаряда), то я жду ответа.

прекращай плакать. при чем тут ваши тёрки с SeVa? на WinForms и XAML ты сам съехал. я ничего тебе про них не говорил. однако ты сам закопался... я тебе отвечу на твой вопрос, если ты сначала ответишь мне на мой (в который раз уже заданный, но старательно специально для тебя мною разжёванный):

1. реализация фильтра требует зависимость в виде компонента ISomeService, которую получает через открытое свойство.
2. реализация контроллера требует зависимость в виде компонента ISomeService, которую получает через конструктор.
3. реализация вью требует зависимость в виде компонента ISomeService, которую получает через конструктор.
4. компонент ISomeService наследует интерфейс IDisposable

вопрос. кто должен в итоге уничтожить компонент? почему?
...
Рейтинг: 0 / 0
выбор IoC
    #38475424
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУГлупость несусветная. Я тебе привел элементарную задачу, где это не работает. Ты не стал её решать, а тупо съехал.

я не понимаю, зачем приводить даже элементарную задачу, но сильно выходящую за рамки темы? а задача и впрямь элементарная. ты ещё в драйвера подайся, а типо там как ты решишь эту задачу, а? аа-ааа?? а на ассемблере?? а на Brainfack-e? а в контроллере моего холодильника? что? съел? то-то же.

ты давай не отклоняйся от четко обсуждаемой темы. это еще при том, что ты палишься в случае с WinForms и XAML — типа там понятие Lifetime Scope не применимо, не? это раз. во-вторых, вместо уничтожения можно уведомить контейнер, что объект больше не нужен (про счётчики ссылок, семафоры, что-нибудь слыхал?)... неужели такие элементарные вещи надо объяснять.
...
Рейтинг: 0 / 0
выбор IoC
    #38475430
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
специально для тех, кто решил отсидеться в глухом непроглядном танке:

Код: c#
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
public class FormFactory
{
    readonly ILifetimeScope scope;

    public FormFactory(ILifetimeScope scope)
    {
        this.scope = scope;
    }

    public TForm CreateForm<TForm>() where TForm : Form
    {
        var formScope = scope.BeginLifetimeScope("FormScope");
        var form = formScope.Resolve<TForm>();
        form.Closed += (s, e) => formScope.Dispose();
        return form;
    }
}



на случай тупейшей ереси типа «о боже, это в ваших asp.net-ах есть всякие HttpContext-ы, а в наших винформсах ничего такого и подавно ж нет! никто не знает какие формы когда открываются и когда закрываются, не уследишь, такой бедлам творится, я даже незнаю, даже незнаю....» (и куриные помахивания руками)...

не позорьте-съ.
...
Рейтинг: 0 / 0
выбор IoC
    #38475450
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SeVaПеречитал еще раз твою хрень,вернее, надпись на заборе в одной из помоек, где ты привык ошиваться
Что-то часто ты стал перечитывать мои сообщения. Маразматический диссонанс?

SeVaМСУВ нем описывается способ регистрации услуг и найти их.
Что это за бред? Моя твоя не понимай.
Потому что нечем понимать, всё просто.

http://msdn.microsoft.com/en-us/library/system.web.mvc.dependencyresolver(v=vs.98).aspx Provides a registration point for dependency resolvers that implement IDependencyResolver or the Common Service Locator IServiceLocator interface.

Переводчик требуется или сам осилишь своим тупым мозгом?

SeVaЧмо, а по делу что-то можешь сказать? Ты как та мартышка, когда ей наступят на хвост, начинает истошно орать и бросаться шкурками от банана в виде картинок.
На большее не способен, урод от программирования?
Что можно сказать по делу конченой маразматичке, которая даже читать не умеет. Я уж молчу про думать. Перечитывай снова и снова, пока не прозреешь, дятел Российской Федерации.
...
Рейтинг: 0 / 0
выбор IoC
    #38475452
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttна WinForms и XAML ты сам съехал. я ничего тебе про них не говорил. однако ты сам закопался...
Я тебе привел реальный показательный, где это работает. Чтобы ты не мыслил единым шаблоном в контексте веба.

hVosttя тебе отвечу на твой вопрос, если ты сначала ответишь мне на мой (в который раз уже заданный, но старательно специально для тебя мною разжёванный)
Стоп. Покажи мне ссылку на эти несколько дублей вопросов, которые я старательно проигнорировал. Если найдешь, тогда я поиграю с тобой в еврейские игры. А пока будь добр ответить на мой вопрос.

hVostt1. реализация фильтра требует зависимость в виде компонента ISomeService, которую получает через открытое свойство.
2. реализация контроллера требует зависимость в виде компонента ISomeService, которую получает через конструктор.
3. реализация вью требует зависимость в виде компонента ISomeService, которую получает через конструктор.
4. компонент ISomeService наследует интерфейс IDisposable
вопрос. кто должен в итоге уничтожить компонент? почему?
Два пути (в зависимости от типа сервиса): либо контроллер, либо контейнер. Я уже писал про это.
...
Рейтинг: 0 / 0
выбор IoC
    #38475453
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttМСУГлупость несусветная. Я тебе привел элементарную задачу, где это не работает. Ты не стал её решать, а тупо съехал.

я не понимаю, зачем приводить даже элементарную задачу, но сильно выходящую за рамки темы? а задача и впрямь элементарная. ты ещё в драйвера подайся, а типо там как ты решишь эту задачу, а? аа-ааа?? а на ассемблере?? а на Brainfack-e? а в контроллере моего холодильника? что? съел? то-то же.

ты давай не отклоняйся от четко обсуждаемой темы. это еще при том, что ты палишься в случае с WinForms и XAML — типа там понятие Lifetime Scope не применимо, не? это раз. во-вторых, вместо уничтожения можно уведомить контейнер, что объект больше не нужен (про счётчики ссылок, семафоры, что-нибудь слыхал?)... неужели такие элементарные вещи надо объяснять.
Где конкретный ответ на мой вопрос? Ты долго будешь позориться?
...
Рейтинг: 0 / 0
выбор IoC
    #38475454
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУГде конкретный ответ на мой вопрос? Ты долго будешь позориться?

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

осточертело трещать с оппонентом, который дурака включает. хотя вроде и не дурак... хз в общем. я на твой вопрос выше ответил. не дожидаясь твоего ответа при чём.
...
Рейтинг: 0 / 0
выбор IoC
    #38475455
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУДва пути (в зависимости от типа сервиса): либо контроллер, либо контейнер. Я уже писал про это.

в какой ещё зависимости? можешь пояснить? и где ты писал про это?
...
Рейтинг: 0 / 0
выбор IoC
    #38475458
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttспециально для тех, кто решил отсидеться в глухом непроглядном танке:

Код: c#
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
public class FormFactory
{
    readonly ILifetimeScope scope;

    public FormFactory(ILifetimeScope scope)
    {
        this.scope = scope;
    }

    public TForm CreateForm<TForm>() where TForm : Form
    {
        var formScope = scope.BeginLifetimeScope("FormScope");
        var form = formScope.Resolve<TForm>();
        form.Closed += (s, e) => formScope.Dispose();
        return form;
    }
}



на случай тупейшей ереси типа «о боже, это в ваших asp.net-ах есть всякие HttpContext-ы, а в наших винформсах ничего такого и подавно ж нет! никто не знает какие формы когда открываются и когда закрываются, не уследишь, такой бедлам творится, я даже незнаю, даже незнаю....» (и куриные помахивания руками)...

не позорьте-съ.

Что это за высер? Ты читал мой код? Форма при создании обращается к веб сервису и сразу после получения ответа диспоузит экземпляр сервиса. Во-вторых, где остальной код? Где вызов и инициализация твоего ILifetimeScope или что там. Приведи полный пример, как я, а не этот огрызок.
...
Рейтинг: 0 / 0
выбор IoC
    #38475459
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttМСУГде конкретный ответ на мой вопрос? Ты долго будешь позориться?

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

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

Я ответил выше на твой всплеск эмоций. Умей ждать ответ, а не прыгать как обезьяна вокруг да около.
...
Рейтинг: 0 / 0
выбор IoC
    #38475460
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttМСУДва пути (в зависимости от типа сервиса): либо контроллер, либо контейнер. Я уже писал про это.

в какой ещё зависимости? можешь пояснить? и где ты писал про это?

В очередной раз убеждаюсь, что читаешь ты задним местом. Вот тут писал на твой вопрос "кто диспозит?": 15174546
...
Рейтинг: 0 / 0
выбор IoC
    #38475463
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУЧто это за высер? Ты читал мой код? Форма при создании обращается к веб сервису и сразу после получения ответа диспоузит экземпляр сервиса. Во-вторых, где остальной код? Где вызов и инициализация твоего ILifetimeScope или что там. Приведи полный пример, как я, а не этот огрызок.

при чем тут остальной код? при чем тут инициализация ILifetimeScope? это к вопросу не относится. речь шла о форме, и о том, как утилизировать ресурсы полученные формой.

твой вариант: явно вызвать диспозе.

мой вариант: вызвать диспозе у ILifetimeScope при закрытии формы.

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

в твоём случае, надо явно знать о том, что какие-то зависимости надо диспозить. если ты не понимаешь что это плохо, твои проблемы. не собираюсь тебя переубеждать в этом. считай что это правильно и говнокодь дальше.
...
Рейтинг: 0 / 0
выбор IoC
    #38475464
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУВ MVC базовый контроллер, как вариант. Может и контроллер наследник, если потребуется какая-то нештатная ситуация.

перефразируя, твой ответ, это

ХЗ КТО!

я решил уточнить. но видимо ошибся. ты действительно без понятия...
...
Рейтинг: 0 / 0
выбор IoC
    #38475465
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttвызвать диспозе у ILifetimeScope при закрытии формы.

и не прикапывайся к этим словам. типа что это ещё за ILifetimeScope и кто его создаёт.
это решение лишь ответ на твой вопрос "как?", вариантов много. главное принцип, который я уже озвучил. не подойдёт такой ответ: ХЗ КТО В ЗАВИСИМОСТИ ОТ СИТУАЦИИ. мы же про DI говорим? или уже пошли во все тяжкие?
...
Рейтинг: 0 / 0
выбор IoC
    #38475467
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVostthVosttвызвать диспозе у ILifetimeScope при закрытии формы.

и не прикапывайся к этим словам. типа что это ещё за ILifetimeScope и кто его создаёт.
это решение лишь ответ на твой вопрос "как?", вариантов много. главное принцип, который я уже озвучил. не подойдёт такой ответ: ХЗ КТО В ЗАВИСИМОСТИ ОТ СИТУАЦИИ. мы же про DI говорим? или уже пошли во все тяжкие?

Вот главный ответ. Я рад, что ты, наконец, это понял. Диспоузить можно и контейнером для классических рядовых случаев, диспоузить можно и инициатором. Не стоит жить одним шаблоном.
...
Рейтинг: 0 / 0
выбор IoC
    #38475468
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttМСУВ MVC базовый контроллер, как вариант. Может и контроллер наследник, если потребуется какая-то нештатная ситуация.

перефразируя, твой ответ, это

ХЗ КТО!

я решил уточнить. но видимо ошибся. ты действительно без понятия...

Ты о чем?
...
Рейтинг: 0 / 0
выбор IoC
    #38475470
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttМСУЧто это за высер? Ты читал мой код? Форма при создании обращается к веб сервису и сразу после получения ответа диспоузит экземпляр сервиса. Во-вторых, где остальной код? Где вызов и инициализация твоего ILifetimeScope или что там. Приведи полный пример, как я, а не этот огрызок.

при чем тут остальной код? при чем тут инициализация ILifetimeScope? это к вопросу не относится. речь шла о форме, и о том, как утилизировать ресурсы полученные формой.
Зачем мне утилизация по закрытию? Где инициализация веб сервиса? Что за гавнокод ты вбросил?
...
Рейтинг: 0 / 0
выбор IoC
    #38475480
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУВот главный ответ. Я рад, что ты, наконец, это понял. Диспоузить можно и контейнером для классических рядовых случаев, диспоузить можно и инициатором. Не стоит жить одним шаблоном.

полностью согласен, что не стоит жить одним шаблоном.

но! если уж применяешь шаблон (в данном случае DI), то стоит идти до конца.

вот твой пример:

Код: c#
1.
2.
3.
4.
5.
6.
7.
8.
9.
public void OpenEmployeesWindow()
{
    var view = new EmployeesWindow();
    view.Owner = ActiveWindow;
    var vm = new EmployeesViewModel(App.Container); // 
    view.DataContext = vm;
    view.Show();
    view.Closed += (a, b) => { vm.Dispose(); Application.Current.MainWindow.Focus(); };
}



есть две проблемы.

намбер уан: всё-таки стоит применять фабрику, а не творить "чудеса" в методе. сопровождать такое — ад. творить такое — бэд.

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

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

приведу ещё раз мой код.

Код: c#
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
public class FormFactory
{
    readonly ILifetimeScope scope;

    public FormFactory(ILifetimeScope scope)
    {
        this.scope = scope;
    }

    public TForm CreateForm<TForm>() where TForm : Form
    {
        var formScope = scope.BeginLifetimeScope("FormScope");
        var form = formScope.Resolve<TForm>();
        form.Closed += (s, e) => formScope.Dispose();
        return form;
    }
}



и твой


Код: c#
1.
2.
3.
4.
5.
public void OpenEmployeesWindow()
{
   var factory = new FormFactory(App.Container);
   return factory.CreateForm<EmployeesWindow>();
}



всё. таким образом, все зависимости формы будут резолвены нужным образом, и каждая зависимость умрёт только тогда, когда ЕЙ будет нужно. а последнее определяется там, где эти зависимости регитсрируется. т.е. в том модуле, где находится компонент.

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

давайте писать хороший, сопровождаемый код?
...
Рейтинг: 0 / 0
выбор IoC
    #38475482
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУЗачем мне утилизация по закрытию? Где инициализация веб сервиса? Что за гавнокод ты вбросил?

я не знаю зачем тебе утилизация по закрытию. я даже не собирался здесь ради треда писать целые проекты с грамотной интеграцией DI, думаю ты и сам можешь с этим справится. я тебе пояснил принцип минимальным кодом. не понятно? ну а я не заявлял, что я офигенный учитель. дуй в гугл, если что-то не понятно. или задавай конкретные вопросы в рамках темы. итак уже тебя шатает.
...
Рейтинг: 0 / 0
выбор IoC
    #38475484
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУ,

и ещё. я хз как такое УГ можно тестировать:

Код: c#
1.
2.
3.
4.
5.
6.
7.
8.
9.
public void OpenEmployeesWindow()
{
    var view = new EmployeesWindow();
    view.Owner = ActiveWindow;
    var vm = new EmployeesViewModel(App.Container); // 
    view.DataContext = vm;
    view.Show();
    view.Closed += (a, b) => { vm.Dispose(); Application.Current.MainWindow.Focus(); };
}



совершенно однозначно на помойку. даже если ты считаешь это неогранённым бриллиантом в программировании. /dev/nul -- такому коду самое место.
...
Рейтинг: 0 / 0
выбор IoC
    #38475505
SeVa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУSeVaПеречитал еще раз твою хрень,вернее, надпись на заборе в одной из помоек, где ты привык ошиваться
Что-то часто ты стал перечитывать мои сообщения. Маразматический диссонанс?

SeVaпропущено...

Что это за бред? Моя твоя не понимай.
Потому что нечем понимать, всё просто.

http://msdn.microsoft.com/en-us/library/system.web.mvc.dependencyresolver(v=vs.98).aspx Provides a registration point for dependency resolvers that implement IDependencyResolver or the Common Service Locator IServiceLocator interface.

Переводчик требуется или сам осилишь своим тупым мозгом?

SeVaЧмо, а по делу что-то можешь сказать? Ты как та мартышка, когда ей наступят на хвост, начинает истошно орать и бросаться шкурками от банана в виде картинок.
На большее не способен, урод от программирования?
Что можно сказать по делу конченой маразматичке, которая даже читать не умеет. Я уж молчу про думать. Перечитывай снова и снова, пока не прозреешь, дятел Российской Федерации.

Ты можешь читать только надписи на заборах и не можешь осилить код в 10 строчек.
В документации msdn в конце есть ссылка на статью, где описываются отличия, которые я тебе озвучил
For more information about IDependencyResolver, see the entry ASP.NET MVC 3 Service Location on Brad Wilson's blog.Differences between IDependencyResolver and Common Service Locator
The primary difference between IDependencyResolver and Common Service Locator centers around exceptions. Where Common Service Locator expects you to throw exceptions on single-service lookup failure, IDependencyResolver's GetService() method expects you to return null on single-service lookup failure.

Both interfaces expect you to return an empty collection (not null) for multi-service lookup when there are no registered services.

Те отличия чисто номинальные, а суть одна.
Ты порол лажу, в mvc никогда не было и не будет своего di контейнера. В mvc 3 был чистый локатор, а в 4 его разновидность.
Заруби это на своем тупом лбу и не пачкай здесь мозги другим.
...
Рейтинг: 0 / 0
выбор IoC
    #38475507
SeVa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttМСУ,

и ещё. я хз как такое УГ можно тестировать:

Код: c#
1.
2.
3.
4.
5.
6.
7.
8.
9.
public void OpenEmployeesWindow()
{
    var view = new EmployeesWindow();
    view.Owner = ActiveWindow;
    var vm = new EmployeesViewModel(App.Container); // 
    view.DataContext = vm;
    view.Show();
    view.Closed += (a, b) => { vm.Dispose(); Application.Current.MainWindow.Focus(); };
}




совершенно однозначно на помойку. даже если ты считаешь это неогранённым бриллиантом в программировании. /dev/nul -- такому коду самое место.

чмо смогло применить di контейнер как тупой локатор и не более, тем самым убивая саму идею первых на корню.
...
Рейтинг: 0 / 0
выбор IoC
    #38475517
Фотография Изопропил
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУНе стоит жить одним шаблоном
до пациента не дойдёт
...
Рейтинг: 0 / 0
выбор IoC
    #38475541
SeVa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ИзопропилМСУНе стоит жить одним шаблоном
до пациента не дойдёт

А до Главного Пациента никак не дойдет, что не стоит жить одним говносервисом на все случаи жизни.

Муся, таскай контролы дальше и не мучай свою задницу непосильными для тебя вещами. Надорвешь ее
...
Рейтинг: 0 / 0
выбор IoC
    #38475573
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Изопропилдо пациента не дойдёт

а вы типо местная чирлидерша в поддержку МСУ?

хоть какие-нибудь намёки на осмысленную речь будут?
...
Рейтинг: 0 / 0
выбор IoC
    #38475574
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУ,

надеюсь ты дочитаешь тред до этого места, прежде чем комментить.


Код: c#
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
public void OpenEmployeesWindow()
{
   var factory = new FormFactory(App.Container);
   var view = factory.CreateForm<EmployeesWindow>();

   // хотя уместно такие вещи делать через фабрику
   view.Owner = ActiveWindow;
   view.Closed += (a, b) => { Application.Current.MainWindow.Focus(); };

   // форма резолвит это через DI:
   // view.DataContext = vm;

   view.Show();
}
...
Рейтинг: 0 / 0
выбор IoC
    #38475602
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SeVaТы можешь читать только надписи на заборах и не можешь осилить код в 10 строчек.
В документации msdn в конце есть ссылка на статью, где описываются отличия, которые я тебе озвучил

Тупица, если бы ты умел читать глазами, а не задницей, то прочитал бы: 15172850
Об этом я уже писал, что сначала в MVC был обычный локатор.

SeVaТе отличия чисто номинальные, а суть одна.
Ты порол лажу, в mvc никогда не было и не будет своего di контейнера. В mvc 3 был чистый локатор, а в 4 его разновидность.
Заруби это на своем тупом лбу и не пачкай здесь мозги другим.
А в MVC 4 и выше сделали обычный DI контейнер. Ты просто упоротая обезьяна.

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

ИзопропилМСУНе стоит жить одним шаблоном
до пациента не дойдёт
Вижу, бесполезное это дело.
...
Рейтинг: 0 / 0
выбор IoC
    #38475607
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttМСУВот главный ответ. Я рад, что ты, наконец, это понял. Диспоузить можно и контейнером для классических рядовых случаев, диспоузить можно и инициатором. Не стоит жить одним шаблоном.

полностью согласен, что не стоит жить одним шаблоном.

но! если уж применяешь шаблон (в данном случае DI), то стоит идти до конца.

вот твой пример:

Код: c#
1.
2.
3.
4.
5.
6.
7.
8.
9.
public void OpenEmployeesWindow()
{
    var view = new EmployeesWindow();
    view.Owner = ActiveWindow;
    var vm = new EmployeesViewModel(App.Container); // 
    view.DataContext = vm;
    view.Show();
    view.Closed += (a, b) => { vm.Dispose(); Application.Current.MainWindow.Focus(); };
}



есть две проблемы.

намбер уан: всё-таки стоит применять фабрику, а не творить "чудеса" в методе. сопровождать такое — ад. творить такое — бэд.

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

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

приведу ещё раз мой код.

Код: c#
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
public class FormFactory
{
    readonly ILifetimeScope scope;

    public FormFactory(ILifetimeScope scope)
    {
        this.scope = scope;
    }

    public TForm CreateForm<TForm>() where TForm : Form
    {
        var formScope = scope.BeginLifetimeScope("FormScope");
        var form = formScope.Resolve<TForm>();
        form.Closed += (s, e) => formScope.Dispose();
        return form;
    }
}



и твой


Код: c#
1.
2.
3.
4.
5.
public void OpenEmployeesWindow()
{
   var factory = new FormFactory(App.Container);
   return factory.CreateForm<EmployeesWindow>();
}



всё. таким образом, все зависимости формы будут резолвены нужным образом, и каждая зависимость умрёт только тогда, когда ЕЙ будет нужно. а последнее определяется там, где эти зависимости регитсрируется. т.е. в том модуле, где находится компонент.

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

давайте писать хороший, сопровождаемый код?

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

1. Во-первых, это не просто метод. Это метод сервиса, который инициализирует окно. Эту супер сложную задачу не нужно перекладывать еще на какую-то абстракцию, так как это параноя.
2. Про второй пункт вообще пордал. DI инкапуслирован в конструктор вью модели и работает там. IWindowService - это простая обвязка для поднятия окна. Окно можно поднимать или простым сервис локатором через Lazy, или обычным слоем, роль которого у меня выполняет IWindowService. Учи матчасть.
3. Да, OpenEmployeesWindow - он умный, его задача поднять и закрыть окно. И всё, что с этим связано. Это не хардкодинг, это классическая элементарная задача.

Ты тупо с помощью какой-то фабрики взял и добавил еще одну абстракцию. Которая реально не нужна. Сопровождать такой высер - преступление. Написать такое может только студент-теоретик с шаблонным мышлением.
...
Рейтинг: 0 / 0
выбор IoC
    #38475609
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttМСУ,

надеюсь ты дочитаешь тред до этого места, прежде чем комментить.


Код: c#
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
public void OpenEmployeesWindow()
{
   var factory = new FormFactory(App.Container);
   var view = factory.CreateForm<EmployeesWindow>();

   // хотя уместно такие вещи делать через фабрику
   view.Owner = ActiveWindow;
   view.Closed += (a, b) => { Application.Current.MainWindow.Focus(); };

   // форма резолвит это через DI:
   // view.DataContext = vm;

   view.Show();
}



Бред чистой воды - те же яйца, только вид с боку. Дополнительный слой, который никому не нужен. Присаживайся, сегодня опять двойка.
...
Рейтинг: 0 / 0
выбор IoC
    #38475631
SeVa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУ,


МСУSeVaТы можешь читать только надписи на заборах и не можешь осилить код в 10 строчек.
В документации msdn в конце есть ссылка на статью, где описываются отличия, которые я тебе озвучил

Тупица, если бы ты умел читать глазами, а не задницей, то прочитал бы: 15172850
Об этом я уже писал, что сначала в MVC был обычный локатор.

SeVaТе отличия чисто номинальные, а суть одна.
Ты порол лажу, в mvc никогда не было и не будет своего di контейнера. В mvc 3 был чистый локатор, а в 4 его разновидность.
Заруби это на своем тупом лбу и не пачкай здесь мозги другим.
А в MVC 4 и выше сделали обычный DI контейнер. Ты просто упоротая обезьяна.

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

Изопропилпропущено...

до пациента не дойдёт
Вижу, бесполезное это дело.
МСУSeVaТы можешь читать только надписи на заборах и не можешь осилить код в 10 строчек.
В документации msdn в конце есть ссылка на статью, где описываются отличия, которые я тебе озвучил

Тупица, если бы ты умел читать глазами, а не задницей, то прочитал бы: 15172850
Об этом я уже писал, что сначала в MVC был обычный локатор.

SeVaТе отличия чисто номинальные, а суть одна.
Ты порол лажу, в mvc никогда не было и не будет своего di контейнера. В mvc 3 был чистый локатор, а в 4 его разновидность.
Заруби это на своем тупом лбу и не пачкай здесь мозги другим.
А в MVC 4 и выше сделали обычный DI контейнер. Ты просто упоротая обезьяна.

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

Изопропилпропущено...

до пациента не дойдёт
Вижу, бесполезное это дело.

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

Даже интересно, что могут делать такие уроды в РЖД?!
...
Рейтинг: 0 / 0
выбор IoC
    #38475636
SeVa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУhVosttМСУ,

надеюсь ты дочитаешь тред до этого места, прежде чем комментить.


Код: c#
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
public void OpenEmployeesWindow()
{
   var factory = new FormFactory(App.Container);
   var view = factory.CreateForm<EmployeesWindow>();

   // хотя уместно такие вещи делать через фабрику
   view.Owner = ActiveWindow;
   view.Closed += (a, b) => { Application.Current.MainWindow.Focus(); };

   // форма резолвит это через DI:
   // view.DataContext = vm;

   view.Show();
}




Бред чистой воды - те же яйца, только вид с боку. Дополнительный слой, который никому не нужен. Присаживайся, сегодня опять двойка.

Пациент, ты собрал все УГ, которое было разбросано по формам в одну большую кучу.
От этого кол-во УГ не убавилось, а вони стало еще больше.
Ты или сломаешь шею, пытаясь разглядеть, что там делается на верху, или переломаешь ноги, когда будешь карабкаться на верх, чтобы прилепить очередной кизяк и в конце-концов эта конструевина обвалится сама и придавит тебя.
Но для десятка формочек(думаю, больше ты не видел) потянет. Куча будет с тебя ростом и не придется становится на табуретку.
Для нормальной жизни нужен сервис навигации, но это уже не для тебя. Ты десять строчек чужого кода осилить не можешь
...
Рейтинг: 0 / 0
выбор IoC
    #38475650
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SeVaЯ перечитал твой бред с жалкими потугами перевода с английского на албанский.
Слишком часто ты перечитываешь. Проблемы с памятью, противоречивость данных? Выбрось мозг, купи когерентность кэша.

SeVaУ тебя полная каша в голове, ты нахватался не понятных тебе терминов без всякого их понимания. Шизняк крепчает и теперь фабрика тоже DI.
Забавно читать такие выводы от шизоида-невростенички, который даже сформулировать свою мысль не в состоянии. Перечитывай лучше мои сообщения, не реагируй.

SeVaУ Эллочки-людоедки появились новые словечки и она их лепит не в тему.
О каких словечках речь, мутирующее чудовище?

SeVaДаже интересно, что могут делать такие уроды в РЖД?!
У тебя окончательно поехала крыша. Каким боком тут РЖД?

SeVaПациент, ты собрал все УГ, которое было разбросано по формам в одну большую кучу.
От этого кол-во УГ не убавилось, а вони стало еще больше.
Перечитай еще раз, ты же любишь перечитывать. Признайся, что не осилил IoC, а теперь какаешь тут всякими глупостями.

SeVaТы или сломаешь шею, пытаясь разглядеть, что там делается на верху, или переломаешь ноги, когда будешь карабкаться на верх, чтобы прилепить очередной кизяк и в конце-концов эта конструевина обвалится сама и придавит тебя.
А ты сломал шею или переломал ноги, когда разбирался с тем, как генерируются сборки в памяти?
...
Рейтинг: 0 / 0
выбор IoC
    #38475674
SeVa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУНа данный момент DependencyResolver может служить полноценным DI контейнером, который и регистрирует и сопоставляет.

Муслима это полноценный албанский, откровенная тупость и не понимание предмета.
Последнее приводит к тому, что ты таскаешь контейнер в контроллеры, те тупо применяешь его как банальный локатор. DI контейнеры хороши тем, что они сами инжектят зависимости, например:


Код: c#
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
public class StupidMCU
{
   [Dependency]
	public IGomnoService1 svr1 { get;set;}

   [Dependency]
	public IGomnoService2 svr2 { get;set;}

   [Dependency]
	public IGomnoService1 svr1 { get;set;}

}


В unity нужно будет регистрировать только сервисы по отдельности один раз, а тупой мартышке с "полноценным DI" придется переопределять все, где они встречаются.
Я понимаю, что твоей тупой заднице это не создаст проблему, для нее важно только навалить под каждой елкой, но для других такой вариант не пройдет.
Чтобы этого не происходило умные дяди делают нормальные фреймворки, с которыми мсушечки не смогут все засрать по самое не хочу. Все что от них требуется - нарисовать форму и наковырять контроллер, которые при необходимости можно будет быстро переписать.
А в твоих километровых "концептах" без безопасности, навигации, нормальной валидации, кучи необходимых интерфейсов для редактирования в UI, интеграции с БД и тд, будет масса кизяков на ровном месте.

Тренируйся на кошках дальше, чмо подзаборное.
...
Рейтинг: 0 / 0
выбор IoC
    #38475701
Фотография Где-то в степи
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
нифигасе вы все наворотили, привет сева,
не пойму, это альтруизм или война?
...
Рейтинг: 0 / 0
выбор IoC
    #38475711
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SeVaМуслима это полноценный албанский, откровенная тупость и не понимание предмета.
Последнее приводит к тому, что ты таскаешь контейнер в контроллеры, те тупо применяешь его как банальный локатор.
Долбосева, это полноценный русский, с которым у тебя постоянно проблемы из-за отсутствия башки на плечах. Ты полная шизофреничка, что ли? Десятый раз повторяю - локатор только ищет.

SeVaDI контейнеры хороши тем, что они сами инжектят зависимости, например:
Маленький, я лучше тебя знаю, чем хороша инъекция, и знал это, пока ты ламером тут по форуму скитался, когда тебе каждый второй ламер поджопники отвешивал за твою тупость. Иди эту песню спой таким же как ты идиотам. В MVC штатно инъекцию можно сделать другими способами, не обязательно DI контейнером. Ты просто тупая обезьянка и до сих пор это не осознала.

SeVaВ unity нужно будет регистрировать только сервисы по отдельности один раз, а тупой мартышке с "полноценным DI" придется переопределять все, где они встречаются.
Я тебе уже писал, как в DependencyResolver регистрируется сервисы. Иди учи матчать, клоун подзаборный.

SeVaТренируйся на кошках дальше, чмо подзаборное.
Пойду тренироваться с генерацией сборок в памяти, тупое чудовище.
...
Рейтинг: 0 / 0
выбор IoC
    #38475733
SeVa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУМаленький, я лучше тебя знаю, чем хороша инъекция, и знал это, пока ты ламером тут по форуму скитался, когда тебе каждый второй ламер поджопники отвешивал за твою тупость. Иди эту песню спой таким же как ты идиотам. В MVC штатно инъекцию можно сделать другими способами, не обязательно DI контейнером. Ты просто тупая обезьянка и до сих пор это не осознала.

SeVaВ unity нужно будет регистрировать только сервисы по отдельности один раз, а тупой мартышке с "полноценным DI" придется переопределять все, где они встречаются.
Я тебе уже писал, как в DependencyResolver регистрируется сервисы. Иди учи матчать, клоун подзаборный.

SeVaТренируйся на кошках дальше, чмо подзаборное.
Пойду тренироваться с генерацией сборок в памяти, тупое чудовище.

Чмо, ты ничего не знаешь и никогда не применял di, а постоянно вонял на форумах, что они не нужны.
Ты не спрыгивай с темы и покажи конкретный говнокод, который у тебя будет с "полноценным DI"
Код: c#
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
public class StupidMCUViewModel1
{
   [Dependency]
	public IGomnoService1 svr1 { get;set;}

   [Dependency]
	public IGomnoService2 svr2 { get;set;}

   [Dependency]
	public IGomnoService1 svr1 { get;set;}

}

public class StupidMCU2
{
   [Dependency]
	public IGomnoService1 svr1 { get;set;}

   [Dependency]
	public IGomnoService2 svr2 { get;set;}


}

public class StupidMCU3
{
   [Dependency]
	public IGomnoService1 svr1 { get;set;}

  

}


и еще вариант, до которого ты еще не дорос, но он нужен, чтобы не плодить классы на ровном месте.
Код: c#
1.
2.
3.
4.
5.
public class ViewModed<TModel>
{
    public TModel Model { get; set; }
    public ISomeService<TModel> { get; set; }
}



Условие только одно - в классах не должно быть контейнера.
...
Рейтинг: 0 / 0
выбор IoC
    #38475738
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SeVaЧмо, ты ничего не знаешь и никогда не применял di, а постоянно вонял на форумах, что они не нужны.
Ты не спрыгивай с темы и покажи конкретный говнокод, который у тебя будет с "полноценным DI"
Тупая обезьяна, где я писал о том, что они не нужны? Каждой задаче своя кобыла. И прекрати постить свой ламерский гавнокод, пойди его покажи детям в яслях. Твой уровень.

SeVaУсловие только одно - в классах не должно быть контейнера.
Идиотское условие, которое придумал идиот. Твоя тема.
...
Рейтинг: 0 / 0
выбор IoC
    #38475749
SeVa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУSeVaЧмо, ты ничего не знаешь и никогда не применял di, а постоянно вонял на форумах, что они не нужны.
Ты не спрыгивай с темы и покажи конкретный говнокод, который у тебя будет с "полноценным DI"
Тупая обезьяна, где я писал о том, что они не нужны? Каждой задаче своя кобыла. И прекрати постить свой ламерский гавнокод, пойди его покажи детям в яслях. Твой уровень.

SeVaУсловие только одно - в классах не должно быть контейнера.
Идиотское условие, которое придумал идиот. Твоя тема.

Чмо, тебе, естественно, не нужны, но это совсем не означает необходимости для других.
Речь о другом, ты утверждал на голубом глазу, что в mvc есть "полноценный DI", продемонстрируй это, а не сливайся в канализацию. Требуется показать обычный мизер из функционала нормальных контейнеров.
Где твой говнокод? Пусть другие полюбуются и еще раз убедятся, что ты урод.
...
Рейтинг: 0 / 0
выбор IoC
    #38475751
SeVa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУSeVaУсловие только одно - в классах не должно быть контейнера.
Идиотское условие, которое придумал идиот. Твоя тема.

Это нормальный вариант, а не то убожество, которое ты демонстрируешь.
В нормальных фреймворках это обычные практики(посмотри примеры prism, mvc, etc)/
А в наколенных поделках тот говнокод с локатором, которым ты здесь гадишь.
...
Рейтинг: 0 / 0
выбор IoC
    #38475754
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SeVaЧмо, тебе, естественно, не нужны, но это совсем не означает необходимости для других.
Речь о другом, ты утверждал на голубом глазу, что в mvc есть "полноценный DI", продемонстрируй это, а не сливайся в канализацию. Требуется показать обычный мизер из функционала нормальных контейнеров.
Где твой говнокод? Пусть другие полюбуются и еще раз убедятся, что ты урод.
Тварь, ни только мне, а вообще никому. Выбрось на помойку свои ламерские потуги, с которыми знакомы даже дети.
Речь именно о том, что в MVC есть DI контейнер. И имя ему DependencyResolver. Я уже раз 10 продемонстрировал его возможности, я же не виноват, что у тебя головы - коровье вымя. Перечитай топик заново, я все фичи уже перечислял много раз.
Так что бестолочь сиди у себя в отстойнике и генери сборки в пямяти, и не смеши популяцию форума своей клоунадой.

SeVaЭто нормальный вариант, а не то убожество, которое ты демонстрируешь.
В нормальных фреймворках это обычные практики(посмотри примеры prism, mvc, etc)/
А в наколенных поделках тот говнокод с локатором, которым ты здесь гадишь.
Это не вариант, это УГ на лопате, бестолочь. Про призм я тебе уже говорил - выбрось эту ламерскую поделку и иди в форум ПТ посмеши людей. Практик у тебя нет и не было, ты обычный быдлокодер без грамма ума и фантазии, который генерит сборки в памяти. Кому нужны практики от такого чучела, как ты?
...
Рейтинг: 0 / 0
выбор IoC
    #38475769
Фотография Изопропил
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
условие не идиотское, должны быть серьёзные основания, чтобы иметь зависимость от контейнера
...
Рейтинг: 0 / 0
выбор IoC
    #38475780
SeVa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУSeVaЧмо, тебе, естественно, не нужны, но это совсем не означает необходимости для других.
Речь о другом, ты утверждал на голубом глазу, что в mvc есть "полноценный DI", продемонстрируй это, а не сливайся в канализацию. Требуется показать обычный мизер из функционала нормальных контейнеров.
Где твой говнокод? Пусть другие полюбуются и еще раз убедятся, что ты урод.
Тварь, ни только мне, а вообще никому. Выбрось на помойку свои ламерские потуги, с которыми знакомы даже дети.
Речь именно о том, что в MVC есть DI контейнер. И имя ему DependencyResolver. Я уже раз 10 продемонстрировал его возможности, я же не виноват, что у тебя головы - коровье вымя. Перечитай топик заново, я все фичи уже перечислял много раз.
Так что бестолочь сиди у себя в отстойнике и генери сборки в пямяти, и не смеши популяцию форума своей клоунадой.

SeVaЭто нормальный вариант, а не то убожество, которое ты демонстрируешь.
В нормальных фреймворках это обычные практики(посмотри примеры prism, mvc, etc)/
А в наколенных поделках тот говнокод с локатором, которым ты здесь гадишь.
Это не вариант, это УГ на лопате, бестолочь. Про призм я тебе уже говорил - выбрось эту ламерскую поделку и иди в форум ПТ посмеши людей. Практик у тебя нет и не было, ты обычный быдлокодер без грамма ума и фантазии, который генерит сборки в памяти. Кому нужны практики от такого чучела, как ты?

Ламерская поделка у тебя, а призм от ребят, которых папа с мамой не пальцем делали.
Наличие контейнера - жесткая связанность и привязка к одной конкретной реализации, а все нормальные фреймворки этого избегают. MVC в том числе.
Ты обосравшееся чмо, которое ничего не видело кроме своего говна, неспособное даже разобраться в 10 чужих строчках, но привыкшее вякать о том, что в глаза не видело.
Твои нелепые экзерсисы с DI - это поведение блондинки, у которой есть автоматическая коробка, а она об этом даже не догадывается, возит с собой ручную в багажнике.
...
Рейтинг: 0 / 0
выбор IoC
    #38475782
Фотография Изопропил
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SeVaповедение блондинки, у которой есть автоматическая коробка, а она об этом даже не догадывается, возит с собой ручную в багажнике.
это пять!
...
Рейтинг: 0 / 0
выбор IoC
    #38475793
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SeVaЛамерская поделка у тебя, а призм от ребят, которых папа с мамой не пальцем делали.
Наличие контейнера - жесткая связанность и привязка к одной конкретной реализации, а все нормальные фреймворки этого избегают. MVC в том числе.
Ты обосравшееся чмо, которое ничего не видело кроме своего говна, неспособное даже разобраться в 10 чужих строчках, но привыкшее вякать о том, что в глаза не видело.
Твои нелепые экзерсисы с DI - это поведение блондинки, у которой есть автоматическая коробка, а она об этом даже не догадывается, возит с собой ручную в багажнике.
Гнидка, ты о чем? Выпей яду и не смеши людей, ты вообще полный ноль в IoC. Ничего ты не продемонстрировал, разве что один сплошной пионерский код, который может написать любой студент неуч вроде тебя. Какая такая автоматическая коробка, дурень ты изергильский?
...
Рейтинг: 0 / 0
выбор IoC
    #38475798
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУЭто не хардкодинг, это классическая элементарная задача.

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


П.С.

МСУТы тупо с помощью какой-то фабрики взял и добавил еще одну абстракцию. Которая реально не нужна.

офигенная оргументация. с таким подходом только космические коробли строить.... в обще грустно мне что потратил зря с тобой время.
...
Рейтинг: 0 / 0
выбор IoC
    #38475799
SeVa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУ, тебя не спрашивают мнения(ты еще до этого не дорос и никогда не дорастешь уже), а всего лишь дать подтверждение поносу, которым ты залил этот топик.
Вполне ожидаемо, что ты не смог этого сделать, тк в mvc куцый локатор и полноценным di там даже не пахнет.
Обтекай. Прежде, чем поднимать очередную вонь, сначала обсохни чуть-чуть и не смерди тупостью
...
Рейтинг: 0 / 0
выбор IoC
    #38475827
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SeVaМСУ, тебя не спрашивают мнения(ты еще до этого не дорос и никогда не дорастешь уже), а всего лишь дать подтверждение поносу, которым ты залил этот топик.
Вполне ожидаемо, что ты не смог этого сделать, тк в mvc куцый локатор и полноценным di там даже не пахнет.
Обтекай. Прежде, чем поднимать очередную вонь, сначала обсохни чуть-чуть и не смерди тупостью
Долбосева, цена твоих глупых постов равна нулю. Уровень твоих "знаний" оставляет желать лучшего. Зачем ты изливаешь свой поток мыслей, ведь все-равно ты тупорылая макака?
...
Рейтинг: 0 / 0
выбор IoC
    #38475830
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttмда. оставляю тебя при своём мнении. не увидел ни аргументов, ни пояснений. одни только громкие заявления рода "вот так правильно! а так неправильно. я сказал!" . ок, ок... продолжай говнокодить дальше. мне так-то всё равно какого качества ты производишь код. но поучиться, вижу, у тебя абсолютно нечему.
Я же тебе всё на пальцах пояснил и даже вью модель нарисовал, где в конструктор передается контейнер, резолвится сервис, дергается метод, диспоузится. То есть использование сервиса должно быть как можно короче, использовал и утилизировал. Никаких ожиданий до Close. Понимаешь, что я тебе говорю? Если не понимаешь, продолжай дальше писать безумный код, без ума и фантазии. Абстрагироваться можно до 100500 уровней, только толку от этого ноль. Когда научишься понимать, сколько должно быть уровней и какие это уровни - считай повзрослел. Десятый раз повторяю, идеальный вариант, когда вызывающий диспоузит, а не контейнер.

hVosttофигенная оргументация. с таким подходом только космические коробли строить.... в обще грустно мне что потратил зря с тобой время.
Потому что так ничерта и не понял. Впрочем, как всегда.
...
Рейтинг: 0 / 0
выбор IoC
    #38475845
SeVa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУhVosttмда. оставляю тебя при своём мнении. не увидел ни аргументов, ни пояснений. одни только громкие заявления рода "вот так правильно! а так неправильно. я сказал!" . ок, ок... продолжай говнокодить дальше. мне так-то всё равно какого качества ты производишь код. но поучиться, вижу, у тебя абсолютно нечему.
Я же тебе всё на пальцах пояснил и даже вью модель нарисовал, где в конструктор передается контейнер, резолвится сервис, дергается метод, диспоузится. То есть использование сервиса должно быть как можно короче, использовал и утилизировал. Никаких ожиданий до Close. Понимаешь, что я тебе говорю? Если не понимаешь, продолжай дальше писать безумный код, без ума и фантазии. Абстрагироваться можно до 100500 уровней, только толку от этого ноль. Когда научишься понимать, сколько должно быть уровней и какие это уровни - считай повзрослел. Десятый раз повторяю, идеальный вариант, когда вызывающий диспоузит, а не контейнер.

hVosttофигенная оргументация. с таким подходом только космические коробли строить.... в обще грустно мне что потратил зря с тобой время.
Потому что так ничерта и не понял. Впрочем, как всегда.

Тупость(пишу медленно), тебя просят дать подтверждение функционала di контейнера, а не локатора.
Инверсия - это принцип Голливуда : не надо нам звонить, мы сами позвоним.
Повтор по 50 разу, ты даже не понимаешь о чем речь. Посему путаешь мягкое с теплым и забиваешь микроскопом гвозди.
Помимо этого в твоем говнокоде совершенно не было дженериков.
Урод, посмотри хотя бы одни пример mvc c unity.
...
Рейтинг: 0 / 0
выбор IoC
    #38475847
SeVa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Сам ты ничего не найдешь, вот тебе самый простой для идиотов как ты.
тынц .

В контроллере нет никаких контейнеров. В ms тоже ничего не понимают, один ты у нас умный?
Если вся рота идет в ногу, а только мсу скачет на одной ножке, то это означает только одно - дебил не научился ходить.
...
Рейтинг: 0 / 0
выбор IoC
    #38475848
Фотография Изопропил
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУ. Да и инжектирование многим не нужно, достаточно просто резолвить по месту требования.

МСУвью модель нарисовал, где в конструктор передается контейнер

против этого собственно и возражения
...
Рейтинг: 0 / 0
выбор IoC
    #38475851
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУЯ же тебе всё на пальцах пояснил и даже вью модель нарисовал, где в конструктор передается контейнер, резолвится сервис, дергается метод, диспоузится. То есть использование сервиса должно быть как можно короче, использовал и утилизировал. Никаких ожиданий до Close. Понимаешь, что я тебе говорю? Если не понимаешь, продолжай дальше писать безумный код, без ума и фантазии. Абстрагироваться можно до 100500 уровней, только толку от этого ноль. Когда научишься понимать, сколько должно быть уровней и какие это уровни - считай повзрослел. Десятый раз повторяю, идеальный вариант, когда вызывающий диспоузит, а не контейнер.

бл?*:!. ты резелвишь ВРУЧНУЮ!!!! мать... п....ц. незнаю уже приличных слов. ВРУЧНУЮ !!!!!!! а каком нах DI мы вообще говорим??????? может не надо сюда этот паттерн приплетать, а? делай ты как хочешь, ей богу, не ебай мне мозга человек.

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

и какие 100500 уровней ты о чем???? я так понял у тебя позиция ГОВНОКОДЮ КАК ХОЧУ ,срать на ваши шаблонное мышление.
...
Рейтинг: 0 / 0
выбор IoC
    #38475855
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУ,

сейчас уже я абсолютно на 100% уверен, что ты никоггда в своей жизни TDD не применял. все знания ограничены только теорией, что дескать где-то да, так делают. ни зачто не поверю, чт оможно нести такой бред как ты, если хоть раз приходилось покрывать свой код тестами. при чем добиться полного покрытия. это можно сделать только полностью абстрагировавшись от всего, поручить DI управлять зависимостями, их созданием и уничтожением. только так можно с уверенностью говорить, что паттерн DI применён. а не на пол шишечки как у тебя, незнаю тогда нахера казе баян выкинь ты этот App.Container, не позорься. для когдо этот высер???

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

но нет, приходит один такой весь из себя умный МСУ и заявляет. все вы дибилы и не лечитесь, мыслите шаблонно. надо говнокодить. щас покажу как....
...
Рейтинг: 0 / 0
выбор IoC
    #38475860
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SeVaТупость(пишу медленно), тебя просят дать подтверждение функционала di контейнера, а не локатора.
Дятел, DependencyResolver это и есть функционал DI контейнера. Если нужно что-то более функциональное, возьми Unity, нинжект или еще 100500 иных реализаций.

SeVaИнверсия - это принцип Голливуда : не надо нам звонить, мы сами позвоним.
Почти как: не надо генерить сборки в памяти, мы сами сгенерим.

SeVaПовтор по 50 разу, ты даже не понимаешь о чем речь.
Ты идиот. Выпей уже яду.

SeVaПосему путаешь мягкое с теплым и забиваешь микроскопом гвозди.
См. выше.

SeVaПомимо этого в твоем говнокоде совершенно не было дженериков.
Урод, посмотри хотя бы одни пример mvc c unity.
Дятел, я использую и использовал Unity. Речь вообще о другом - речь о нативном функционале MVC. Убей себя об стену.
...
Рейтинг: 0 / 0
выбор IoC
    #38475862
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SeVaСам ты ничего не найдешь, вот тебе самый простой для идиотов как ты.
тынц .
Кретит, сколько раз убеждаюсь, что ты читаешь задним местом. Именно вот тут я указывал эту статью, бестолочь 15172850

SeVaВ контроллере нет никаких контейнеров. В ms тоже ничего не понимают, один ты у нас умный?
Кретинская морда, какая разница, что инжектить в конструктор, 100500 сервисов или один DI контейнер. Читай вот это, утырок: Dependency injection in ASP.NET MVC with Unity IoC Container

SeVaЕсли вся рота идет в ногу, а только мсу скачет на одной ножке, то это означает только одно - дебил не научился ходить.
Твоя тупость не знает границ, над тобой, калекой, смеется весь SQL.RU.
...
Рейтинг: 0 / 0
выбор IoC
    #38475864
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttМСУЯ же тебе всё на пальцах пояснил и даже вью модель нарисовал, где в конструктор передается контейнер, резолвится сервис, дергается метод, диспоузится. То есть использование сервиса должно быть как можно короче, использовал и утилизировал. Никаких ожиданий до Close. Понимаешь, что я тебе говорю? Если не понимаешь, продолжай дальше писать безумный код, без ума и фантазии. Абстрагироваться можно до 100500 уровней, только толку от этого ноль. Когда научишься понимать, сколько должно быть уровней и какие это уровни - считай повзрослел. Десятый раз повторяю, идеальный вариант, когда вызывающий диспоузит, а не контейнер.

бл?*:!. ты резелвишь ВРУЧНУЮ!!!! мать... п....ц. незнаю уже приличных слов. ВРУЧНУЮ !!!!!!! а каком нах DI мы вообще говорим??????? может не надо сюда этот паттерн приплетать, а? делай ты как хочешь, ей богу, не ебай мне мозга человек.

Что такое резолвить "вручную"? Чем это отличается от резолва "вножную"? Тебя понесло куда-то в болото.

hVosttя тебе пример решения на твоём говнокоде привёл, как заставить DI выполнять свою работу , и не делать эту работу за него ! если эта детсадовская элементарщина до тебя не доходит, я незнаю чо тебе еще сказать. ну нах о чем ещё можно говорить.
Ты привел полный гавнокод, который непримлем даже в детских нетленках. Я тебе уже 10 раз давал задачу - диспоуз сервиса после использования. Где решение?

hVosttи какие 100500 уровней ты о чем???? я так понял у тебя позиция ГОВНОКОДЮ КАК ХОЧУ ,срать на ваши шаблонное мышление.
Вот 100500 уровней: 15180043 Вроде ж разжевал. Или опять ничерта не понял?
...
Рейтинг: 0 / 0
выбор IoC
    #38475865
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttМСУ,

сейчас уже я абсолютно на 100% уверен, что ты никоггда в своей жизни TDD не применял. все знания ограничены только теорией, что дескать где-то да, так делают. ни зачто не поверю, чт оможно нести такой бред как ты, если хоть раз приходилось покрывать свой код тестами. при чем добиться полного покрытия. это можно сделать только полностью абстрагировавшись от всего, поручить DI управлять зависимостями, их созданием и уничтожением. только так можно с уверенностью говорить, что паттерн DI применён. а не на пол шишечки как у тебя, незнаю тогда нахера казе баян выкинь ты этот App.Container, не позорься. для когдо этот высер???

Хвост, я на 200% уверен, что у тебя вообще опыта 0. Сидишь дома, читаешь какой-то тёмный букварь, жжешь тут не по детски о компиляциях лямбды в Expression, о феерическом TDD, понятном только тебе, на одном шаблоне, который вбили тебе в башку. Чудесно. Ты неимоверно крутой TDD-шник, что тут сказать. App.Container - это статика, контейнер на уровне приложения. Что тебя смущает?

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

но нет, приходит один такой весь из себя умный МСУ и заявляет. все вы дибилы и не лечитесь, мыслите шаблонно. надо говнокодить. щас покажу как....
Всё, что ты говоришь - теоретическая куете, не подкрепленная практикой. Твой первый год работы программистиком это реально подтверждает. Что тут можно еще сказать.
...
Рейтинг: 0 / 0
выбор IoC
    #38475873
SeVa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУSeVaСам ты ничего не найдешь, вот тебе самый простой для идиотов как ты.
тынц .
Кретит, сколько раз убеждаюсь, что ты читаешь задним местом. Именно вот тут я указывал эту статью, бестолочь 15172850

SeVaВ контроллере нет никаких контейнеров. В ms тоже ничего не понимают, один ты у нас умный?
Кретинская морда, какая разница, что инжектить в конструктор, 100500 сервисов или один DI контейнер. Читай вот это, утырок: Dependency injection in ASP.NET MVC with Unity IoC Container

SeVaЕсли вся рота идет в ногу, а только мсу скачет на одной ножке, то это означает только одно - дебил не научился ходить.
Твоя тупость не знает границ, над тобой, калекой, смеется весь SQL.RU.


Обязьяка, хаотично бросается шкурками от банана и не понимает, что от нее хотят.
Психиатров здесь нет, а без них тебе ничего не объяснить.

ЗЫ Но надо признать один отрадный факт - дитятко мужает на глазах. Раньше у нее был один ГовноСуперДатаСервис, а теперь уже целых три.
Трудно даже представить, что будет дальше...

С нетерпением ждем продолжения твоей дури, Петросян от программирования.
...
Рейтинг: 0 / 0
выбор IoC
    #38475875
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУТы привел полный гавнокод, который непримлем даже в детских нетленках. Я тебе уже 10 раз давал задачу - диспоуз сервиса после использования. Где решение?

МСУТы привел полный гавнокод, который непримлем даже в детских нетленках.



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

П.С. я привёл код из реального большого и весьма успешного проекта, покрытый тестами на 100%. да и в книжках описываются такие сценарии по внедрению IoC. и даже банальная логика подсказывает, что надо стараться, чтобы было единообразно, а не так "где-то DI уничтожает, где-то клиент диспозит, где-то хз что творится" — это даже не серьезно, и не достойно обсуждения. детский садик, аля-улю-лю.

ещё раз. забей, человек. я признаю, что ты искренне веришь что вроде как говоришь умные вещи. но вот когда сможешь дельно аргументировать свои слова, вот тогда и поговорим. а пока не увидел где ты там чего "разжевал". может забыл кнопку "опубликовать" нажать? ну бывает...
...
Рейтинг: 0 / 0
выбор IoC
    #38475876
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУСидишь дома, читаешь какой-то тёмный букварь, жжешь тут не по детски о компиляциях лямбды в Expression

унылый весьма вброс по поводу Expression. я с тобой закончил демагогию потому, что ты банально не умеешь пользоваться рефлетором, но зато прекрасно можешь дёргать цитаты из MSDN. это всё на что ты оказывается способен. а я то думал...
...
Рейтинг: 0 / 0
выбор IoC
    #38475878
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SeVaОбязьяка, хаотично бросается шкурками от банана и не понимает, что от нее хотят.
Психиатров здесь нет, а без них тебе ничего не объяснить.

ЗЫ Но надо признать один отрадный факт - дитятко мужает на глазах. Раньше у нее был один ГовноСуперДатаСервис, а теперь уже целых три.
Трудно даже представить, что будет дальше...

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

Твоему развитию можно позавидовать. Сначала мембершип осилил с горем пополам, потом паттерны начал изучать, потом кое-как научился генерить сборки в памяти, а теперь на тебе, на DI контейнеры перешел. Умная макака.
...
Рейтинг: 0 / 0
выбор IoC
    #38475879
Фотография Изопропил
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУ Dependency injection in ASP.NET MVC with Unity IoC Container
в этой статье как ни странно инжектится сервис, а не контейнер.....
...
Рейтинг: 0 / 0
выбор IoC
    #38475880
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttдо тебя похоже не доходит. лучше забей. похоже малость не дорос ещё до такого уровня. а я то грешным делом думал, что ты шаришь...
Уровень твоих аргументаций ниже плинтуса. Что тут можно сказать, учись, студент.

hVosttП.С. я привёл код из реального большого и весьма успешного проекта, покрытый тестами на 100%. да и в книжках описываются такие сценарии по внедрению IoC. и даже банальная логика подсказывает, что надо стараться, чтобы было единообразно, а не так "где-то DI уничтожает, где-то клиент диспозит, где-то хз что творится" — это даже не серьезно, и не достойно обсуждения. детский садик, аля-улю-лю.
Маленький, покажи мне хоть одно место в коде, которое я не смогу оттестировать, в том числе с помощью моков. Готов? Подожди, сбегаю за попкорном.

hVosttещё раз. забей, человек. я признаю, что ты искренне веришь что вроде как говоришь умные вещи. но вот когда сможешь дельно аргументировать свои слова, вот тогда и поговорим. а пока не увидел где ты там чего "разжевал". может забыл кнопку "опубликовать" нажать? ну бывает...
Ты просто еще маленький, чтобы понять. Веришь в сказки одной книжки и живешь одним паттерном. Возваращайся, если будет что-то дельное. А пока ты слит.
...
Рейтинг: 0 / 0
выбор IoC
    #38475881
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ИзопропилМСУ Dependency injection in ASP.NET MVC with Unity IoC Container
в этой статье как ни странно инжектится сервис, а не контейнер.....
Не принципиально. Никакой разницы.
...
Рейтинг: 0 / 0
выбор IoC
    #38475882
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttМСУСидишь дома, читаешь какой-то тёмный букварь, жжешь тут не по детски о компиляциях лямбды в Expression

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

Ты со мной закончил демагонию, потому что понял, что постил откровенную чушь. Могу поделиться ссылкой.
...
Рейтинг: 0 / 0
выбор IoC
    #38475883
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУУровень твоих аргументаций ниже плинтуса.

у тебя вообще их нет . никаких. ни выше, и не ниже. и твоя оценка уровня пустая и голословная.
...
Рейтинг: 0 / 0
выбор IoC
    #38475884
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttМСУУровень твоих аргументаций ниже плинтуса.

у тебя вообще их нет . никаких. ни выше, и не ниже. и твоя оценка уровня пустая и голословная.

Как нет? Перечитай ветку, значит, заново.
...
Рейтинг: 0 / 0
выбор IoC
    #38475886
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУКак нет? Перечитай ветку, значит, заново.

вот ты упёртый. будешь до последнего стоять на своём

это конечно похвально. но однако аргументации у тебя практически нет. если ты конечно понимаешь в чём разница между аргументами и бессмысленной оценочной характеристикой.
...
Рейтинг: 0 / 0
выбор IoC
    #38475888
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУИзопропилпропущено...

в этой статье как ни странно инжектится сервис, а не контейнер.....
Не принципиально. Никакой разницы.

вот ещё одно доказательство.

с какого хрена это не принципиально?
с какого хрена никакой разницы?

и так у тебя всегда. вода вода вода...
...
Рейтинг: 0 / 0
выбор IoC
    #38475892
SeVa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttМСУпропущено...

Не принципиально. Никакой разницы.

вот ещё одно доказательство.

с какого хрена это не принципиально?
с какого хрена никакой разницы?

и так у тебя всегда. вода вода вода...

Если бы вода. Один понос
...
Рейтинг: 0 / 0
выбор IoC
    #38475893
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SeVahVosttпропущено...


вот ещё одно доказательство.

с какого хрена это не принципиально?
с какого хрена никакой разницы?

и так у тебя всегда. вода вода вода...

Если бы вода. Один понос

Который у тебя в башке?
...
Рейтинг: 0 / 0
выбор IoC
    #38475894
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttМСУКак нет? Перечитай ветку, значит, заново.

вот ты упёртый. будешь до последнего стоять на своём

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

А зачем тут стоять на своём? Я предоставил вполне рабочий тестируемый вариант - это работает бесперебойно и качественно. Есть множество способов решения подобных задач, обеспечивающих в той или иной степени слабосвязность. Но упорото тыкать в один шаблон - удел глупых обезьянок. Согласен?
...
Рейтинг: 0 / 0
выбор IoC
    #38475896
SeVa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ЗЫ Настоящей блондинке совершенно не принципиально, что ей приходится останавливаться, открывать багажник и дергать привычный рычаг. Она же едет, скажет она. Доказывать, что она полная дура - совершенно бесполезно. Все равно она самая красивая.

Все правильно, МСУ?
...
Рейтинг: 0 / 0
выбор IoC
    #38475897
SeVa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Я опоздал с вопросом. Она уже ответила.
...
Рейтинг: 0 / 0
выбор IoC
    #38475898
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttМСУпропущено...

Не принципиально. Никакой разницы.

вот ещё одно доказательство.

с какого хрена это не принципиально?
с какого хрена никакой разницы?

и так у тебя всегда. вода вода вода...

Ты глупый? С обычного хрена не принципиально - в любом случае обеспечивается слабосвязность, никаких нарушений тут нет. Я лучше передам один контейнер, чем 100500 сервисов. Это стандартная практика.
...
Рейтинг: 0 / 0
выбор IoC
    #38475899
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SeVaЗЫ Настоящей блондинке совершенно не принципиально, что ей приходится останавливаться, открывать багажник и дергать привычный рычаг. Она же едет, скажет она. Доказывать, что она полная дура - совершенно бесполезно. Все равно она самая красивая.

Все правильно, МСУ?

У тебя багажник в больной голове. Я так и не понял, к чему ты ляпнул этот опус. Признайся, что ты шизофреник. Это правда?
...
Рейтинг: 0 / 0
выбор IoC
    #38475901
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУЭто стандартная практика.

только у тебя это стандартная практика . если не так изволь доказать свои слова. не будь обычным словплётом.

ты уже сам оговорился:

МСУЯ лучше передам один контейнер, чем 100500 сервисов.


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

вот банальный пример. если для того, чтобы сменить Unity на Autofac (или наоборот, на важно), нужно перелопать половину кода, это говорит о том, что код -- унылое говно. почему? разве это не очевидно? никакой слабой связности и впомине нет. есть какой-то высер. просто ради того чтобы было. нафига казе баян, ещё раз? выкинь тогда ты эти контейнеры на помойку и пиши всё сам как считаешь нужным.
...
Рейтинг: 0 / 0
выбор IoC
    #38475904
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУв любом случае обеспечивается слабосвязность, никаких нарушений тут нет

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

задача DI -- обеспечивать слабую связность. а не дать Service Locator для самостоятельного разруливания своих зависимостей.

да SL тоже вполне себе инструмент. и неплохой. но это не DI. ты либо одно применяешь, либо другое. определись уже. харе прыгать между этими крайностями как обезьяна. прими, наконец, решение.
...
Рейтинг: 0 / 0
выбор IoC
    #38475905
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttтолько у тебя это стандартная практика . если не так изволь доказать свои слова. не будь обычным словплётом.
Да ради бога, вот чел грамотно отвечает на различные варианты инверсии: WPF with Unity Container - How to register and resolve ViewModels to Views

Пипец, это такая банальщина, что я просто смеюсь с твоей отрешенной тупости :)

hVosttни о какой слабой связности говорить не приходится, если ты начинаешь прокидывать в классы контейнер. классы не должны знать о контейнере. по крайне мере к этому надо всеми силами стремиться.
Млять, да кто ты такой, чтобы утверждать о том, что должны знать классы? Класс вполне себе может знать о контейнере, в чем проблема этого знания? Где сказано, что не должен знать? Ты долго будешь тут исповедовать религию своего единственного паттерна?
...
Рейтинг: 0 / 0
выбор IoC
    #38475907
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУТы долго будешь тут исповедовать религию своего единственного паттерна?

ты дурак? мы говорим о DI. а не о том, лучше он или хуже других подходов. куда тебя несёт?
...
Рейтинг: 0 / 0
выбор IoC
    #38475908
SeVa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttхаре прыгать между этими крайностями как обезьяна. прими, наконец, решение.

Да, MCУ, ты уже решила кто ты? Самая красивая или самая умная?
...
Рейтинг: 0 / 0
выбор IoC
    #38475909
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttМСУв любом случае обеспечивается слабосвязность, никаких нарушений тут нет

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

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

Не понял?
...
Рейтинг: 0 / 0
выбор IoC
    #38475911
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttМСУТы долго будешь тут исповедовать религию своего единственного паттерна?

ты дурак? мы говорим о DI. а не о том, лучше он или хуже других подходов. куда тебя несёт?

Ты кретин? Мы говорим о DI, о чем же еще? Ты тут звездишь о том, что его нельзя подавать классу. Я тебе объясняю, что это бред сивой кобылы. Его спокойно можно отдавать классу. Ты запутался в своих же сетях, рыболов.
...
Рейтинг: 0 / 0
выбор IoC
    #38475912
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SeVahVosttхаре прыгать между этими крайностями как обезьяна. прими, наконец, решение.

Да, MCУ, ты уже решила кто ты? Самая красивая или самая умная?

Каркуша, ты еще не выпила яд?
...
Рейтинг: 0 / 0
выбор IoC
    #38475913
Фотография Изопропил
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Живо представил себе mocking контейнера
...
Рейтинг: 0 / 0
выбор IoC
    #38475916
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУНарушений нет, есть удобство. Когда когда очень много, мне не нужно всё-время править конструкторы классов, чтобы передать еще десяток сервисов. А потом не забыть поправить инжектинг. Я тупо передаю туда интерфейс контейнера и делов. Класс дальше отрезолвит то, что ему нужно. Это универсальность, стабильность и внятность.

Не понял?

я понял. ты не умеешь пользоваться DI, не понимаешь толком зачем он нужен. путаешь SL и DI. но самое главное не это. самое главное вот это:

МСУмне не нужно всё-время править конструкторы классов, чтобы передать еще десяток сервисов

занавес.
...
Рейтинг: 0 / 0
выбор IoC
    #38475917
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttя понял. ты не умеешь пользоваться DI, не понимаешь толком зачем он нужен. путаешь SL и DI. но самое главное не это. самое главное вот это
Я понял, ты не умеешь писать код, никогда не писал боевой код, только читаешь книжки и поносишь в форум какую-то несусветщину. Аплодисменты.
...
Рейтинг: 0 / 0
выбор IoC
    #38475918
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ИзопропилЖиво представил себе mocking контейнера
Расширяй кругозор: Creating a AutoMockingContainer with Microsoft Unity
...
Рейтинг: 0 / 0
выбор IoC
    #38475919
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ИзопропилЖиво представил себе mocking контейнера
Туда же: Mocking IUnityContainer and avoiding BadImageFormatException
...
Рейтинг: 0 / 0
выбор IoC
    #38475920
SeVa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУмне не нужно всё-время править конструкторы классов, чтобы передать еще десяток сервисов

Муфлон, понятия не имеет, что такое unity. Блондинка отжигает дальше.
...
Рейтинг: 0 / 0
выбор IoC
    #38475921
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУТы кретин? Мы говорим о DI, о чем же еще? Ты тут звездишь о том, что его нельзя подавать классу. Я тебе объясняю, что это бред сивой кобылы. Его спокойно можно отдавать классу. Ты запутался в своих же сетях, рыболов.


вот именно. я тебе говорю что его нельзя подавать конечным классам. существует прослойка для внедрения контейнера DI. в ASP.NET MVC она предельно чёткая. это фабрики (контроллеров, вью..)

это позволяет забыть об использовании DependencyResolver. вообще.

у тебя был вопрос, а где же подобная прослойка в WinForms. я показал пример, как организовать такую прослойку (фабрика форм). на что ты сказал, что дескать это лишняя обстракция, нахуа она нужна... занавес, чо.
...
Рейтинг: 0 / 0
выбор IoC
    #38475922
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SeVaМСУмне не нужно всё-время править конструкторы классов, чтобы передать еще десяток сервисов

Муфлон, понятия не имеет, что такое unity. Блондинка отжигает дальше.

Долбосева не знает, что такое .NET и зачем оно надо. Что сказать, тупость неистребима.
...
Рейтинг: 0 / 0
выбор IoC
    #38475923
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУЯ понял, ты не умеешь писать код, никогда не писал боевой код, только читаешь книжки и поносишь в форум какую-то несусветщину. Аплодисменты.

давай, трепыхайся. ещё что скажешь?
...
Рейтинг: 0 / 0
выбор IoC
    #38475925
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУ,

если ты говоришь о десятках сервисов пропихиваемых в класс... это уже говорит о том, что ты нехрена не вдупляешь о понятии SOLID, не понимаешь SRP, и нахрена ты вообще дорвался до DI (хотя юзаешь его, как банальный SL). непонятно в общем. чо там у тебя в башке происходит.
...
Рейтинг: 0 / 0
выбор IoC
    #38475926
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttМСУТы кретин? Мы говорим о DI, о чем же еще? Ты тут звездишь о том, что его нельзя подавать классу. Я тебе объясняю, что это бред сивой кобылы. Его спокойно можно отдавать классу. Ты запутался в своих же сетях, рыболов.


вот именно. я тебе говорю что его нельзя подавать конечным классам. существует прослойка для внедрения контейнера DI. в ASP.NET MVC она предельно чёткая. это фабрики (контроллеров, вью..)

это позволяет забыть об использовании DependencyResolver. вообще.

у тебя был вопрос, а где же подобная прослойка в WinForms. я показал пример, как организовать такую прослойку (фабрика форм). на что ты сказал, что дескать это лишняя обстракция, нахуа она нужна... занавес, чо.

Слушай, да ты много чего говоришь. Диспоузить нельзя, передавать нельзя, ... Что за бред? Выбрось свой паттерн на помойку и не тупи. Можно много чего, нужно просто иметь прямые руки. Если говорить о MVC, я уже писал - ленивый резолв сервисов вообще происходит в конструкторе базового контроллера. И эти сервисы доступны унаследованным контроллерам.

Прекращай нести хрень уже.
...
Рейтинг: 0 / 0
выбор IoC
    #38475927
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttМСУЯ понял, ты не умеешь писать код, никогда не писал боевой код, только читаешь книжки и поносишь в форум какую-то несусветщину. Аплодисменты.

давай, трепыхайся. ещё что скажешь?

Трепыхайся? Смешно это читать от полуграмотного студента, который только что научился программировать :)
...
Рейтинг: 0 / 0
выбор IoC
    #38475929
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttМСУ,

если ты говоришь о десятках сервисов пропихиваемых в класс... это уже говорит о том, что ты нехрена не вдупляешь о понятии SOLID, не понимаешь SRP, и нахрена ты вообще дорвался до DI (хотя юзаешь его, как банальный SL). непонятно в общем. чо там у тебя в башке происходит.

Понесло обезьянку
...
Рейтинг: 0 / 0
выбор IoC
    #38475933
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУМожно много чего, нужно просто иметь прямые руки.

мы не о прямых руках. мы обсуждаем исключительно паттерн DI. я понимаю, что это не панацея, и что прямые руки нужны и голова и всё такое. что не всегда уместно пихать DI, и не надо пытаться сделать +100500 слоёв обстракции... и т.д. и т.п.

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

да в контексте DI диспозить должен контейнер и я уже объяснил почему. могу повторить:

1. принцип единой ответственности (я тибя породил, я тибя и убью)
2. получив зависимость класс не имеет полной информации о том, кому и когда эта зависимость может ещё понадобиться. об этом знает только контейнер. самостоятельно убивая свою зависимость, класс уже обладает какими-то знаниями о сути этой зависимости, т.е. о деталях её реализации, что напрочь сносит всю идею IoC на корню.
3. разное поведение в отношении зависимостей (что-то убивает контейнер, что убивают сами классы), мы создаём хаос. чем больше таких зависимостей, тем сложнее за этим следить. надо знать кто когда и когда уничтожает. и когда когда и кем надо уничтожать. даже для небольшой команды программистов это ад. чтобы его избежать, надо четко определить зону ответственности (пункт 1).

будут какие-то опровергающие аргументы с твоей стороны?
...
Рейтинг: 0 / 0
выбор IoC
    #38475935
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУПонесло обезьянку

не думал, что ты до такого опустишься. в игнор товарищ. иди к своим обезяснкам.
...
Рейтинг: 0 / 0
выбор IoC
    #38475936
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttбудут какие-то опровергающие аргументы с твоей стороны?

МСУ, можешь даже стараться.
я не собираюсь больше продолжать тему, если тебя уже на обезянки понесло.
...
Рейтинг: 0 / 0
выбор IoC
    #38475943
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttМСУМожно много чего, нужно просто иметь прямые руки.
мы не о прямых руках. мы обсуждаем исключительно паттерн DI. я понимаю, что это не панацея, и что прямые руки нужны и голова и всё такое. что не всегда уместно пихать DI, и не надо пытаться сделать +100500 слоёв обстракции... и т.д. и т.п.
Ну вот ты иногда говоришь правильные вещи, а иногда тебя заносит куда-то анус. Хрен поймешь тебя.

hVosttя тебе говорю только что касается в контексте обсуждаемой темы. мы говорим о DI, я говорю как его правильно использовать исходя из большого количества чужого исходного кода, что я прочитал, исходя из прочитанного в книгах уважаемых людей, исходя из банальной логики. я ничего сам не придумал. у тебя привычка перекладывать с больной головы на здоровую.
Не выеживайся. Ты говоришь о некой серебряной пуле. А я тебе объясняю, что жизнь гибче и не нужно мерять всё единым шаблоном. Есть масса решений.

hVosttда в контексте DI диспозить должен контейнер и я уже объяснил почему.
Ты много чего "объяснил", но до сих пор не решил задачу с уничтожением после использования. Классический вариант - открываем окно, идет обращение к WCF сервису, после получения данных инстанс сервиса диспоузится. Где решение?

hVosttбудут какие-то опровергающие аргументы с твоей стороны?
Да. Ты пишешь глупости и про какой-то сферичский хаос. Хаос может быть только в больной голове. Но задача с веб сервисом так и не решена.
...
Рейтинг: 0 / 0
выбор IoC
    #38475945
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttМСУПонесло обезьянку

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

Ну так-то ты быстро сливаешь.

hVostthVosttбудут какие-то опровергающие аргументы с твоей стороны?

МСУ, можешь даже стараться.
я не собираюсь больше продолжать тему, если тебя уже на обезянки понесло.

Только не говори, что обиделся. Принцип обезьянки - упорото делать что-то одно, не замечая альтернатив и иных решений. Я искренне желаю, чтобы ты не превращался в неё. И ни дай тебе быть таким, как упоротый на всю голову Сева. Это еще та невменяемая макака, городит такую жуть, что хоть стой, хоть падай.
...
Рейтинг: 0 / 0
выбор IoC
    #38475952
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУКлассический вариант - открываем окно, идет обращение к WCF сервису, после получения данных инстанс сервиса диспоузится. Где решение?

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

вообще, если мы работаем с DI, то должна быть обеспечена некая инфраструктура. в ASP.NET MVC она есть из коробки. в WinForms её нет, надо позаботиться об этом самому. все окна должны создаваться через фабрику. я даже не вижу причин обсуждать это.

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

всё что я говорил, относится к паттерну DI. к чистому паттерну DI. это когда никакие DependencyResolver или App.Container не используются. никто не резолвит ничего самостоятельно. если тебе кажется, что такие подходы не практикуются, уверяю тебя — это не так. ещё как практикуются.
...
Рейтинг: 0 / 0
выбор IoC
    #38475953
ViPRos
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Нифига не знаю що такив ИоК, ДИ, СЛ- но, мусю опустили кажись по делу
мусь, либо учись, лио пиши кк можешь - иногда как можешь круче чем учиться у козлов каких то
...
Рейтинг: 0 / 0
выбор IoC
    #38475954
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУТы говоришь о некой серебряной пуле.

ещё раз нет. я пытаюсь донести все преимущества использования DI. и это не проброс контейнера в глубь класса типа резолвите там себе что хотите, и делайте с этим что хотите -- это не путь DI. вот что я пытаюсь донести.
...
Рейтинг: 0 / 0
выбор IoC
    #38475957
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ViPRosиногда как можешь круче чем учиться у козлов каких то



и такая точка зрения тоже имеет право на жисть. в сраку ваших Фаулеров, прямые руки и пошёл!...
...
Рейтинг: 0 / 0
выбор IoC
    #38475958
ViPRos
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttМСУТы говоришь о некой серебряной пуле.

ещё раз нет. я пытаюсь донести все преимущества использования DI. и это не проброс контейнера в глубь класса типа резолвите там себе что хотите, и делайте с этим что хотите -- это не путь DI. вот что я пытаюсь донести.
все эти высеры типа ДИ и т.д. латают дыры в ООП, но фигушки, эти дыры бездонны
...
Рейтинг: 0 / 0
выбор IoC
    #38475960
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ViPRosвсе эти высеры типа ДИ и т.д. латают дыры в ООП, но фигушки, эти дыры бездонны

абстракции текут
...
Рейтинг: 0 / 0
выбор IoC
    #38475966
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttа в чем проблема? определяется именованная область жизни, если при регистрации компонента (не имеет значения, что там WCF или что-то ещё, совершенно не важно), указано, что жить он должен в пределах определённой области, значит он и умрёт тогда, когда эта область умрёт. об этом позаботиться контейнер.
Проблема в том, что эту именованную абстракцию области жизни как-то должен протащить в класс. Опять нагружать конструктор. Далее. Класс должен будет в нужный момент сказать, когда выгрузить именованную область. Что по сути те же яйца, что и обычный диспоуз сервиса. Прицнип тот же самый.

hVosttвообще, если мы работаем с DI, то должна быть обеспечена некая инфраструктура. в ASP.NET MVC она есть из коробки. в WinForms её нет, надо позаботиться об этом самому. все окна должны создаваться через фабрику. я даже не вижу причин обсуждать это.
Я с этим не спорю.

hVosttесли же ты выбрал другой подход, использование SL, то совершенно другое дело. диспоузь там, где считаешь нужным. передавай контейнер в глубь классов. я бы так делать не стал, но возможно в этом тоже есть свой смысл. типо с прямыми руками можно и на этом построить хорошую архитектуру.
А какая принципиальная разница в данном контексте, SL или WPF?

hVosttвсё что я говорил, относится к паттерну DI. к чистому паттерну DI. это когда никакие DependencyResolver или App.Container не используются. никто не резолвит ничего самостоятельно. если тебе кажется, что такие подходы не практикуются, уверяю тебя — это не так. ещё как практикуются.
Я же тебе давал ссылки. Практикуются, ибо это удобно. Во-вторых, не все DI контейнеры имеют именованные области жизни. В-третьих, намного проще освободить, чем делегировать освобождение. И самое главное - нету серебряной пули. Вот что я хочу, чтобы ты понял.
...
Рейтинг: 0 / 0
выбор IoC
    #38475967
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttМСУТы говоришь о некой серебряной пуле.

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

Так DI контейнеры разные бывают.
...
Рейтинг: 0 / 0
выбор IoC
    #38475969
ViPRos
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУ,

sl = service locator
...
Рейтинг: 0 / 0
выбор IoC
    #38475970
ViPRos
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
дави их догматиков
...
Рейтинг: 0 / 0
выбор IoC
    #38475974
ViPRos
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУ,

как я понял из базара, ДИ - это типа ресурс менеджера
его просят, если есть такая та фигня, то пжальста запусти ее
а все фигни записывают в ДИ свои координаты
вот ДИ смотрит свой список и если есть такая фигня то запускает ее клон или просто счетчик там увеличивает, пофиг
ну и как то этот счетчик уменшется и тады ДИ выкидывает эту фигню из памяти, а может и не выкидывает фиг знает, кому че надоть
...
Рейтинг: 0 / 0
выбор IoC
    #38475975
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ViPRosМСУ,

sl = service locator

Ок. А то он сначала про ASP.NET, потом про WinForms, потом SL. Сбило с толку :)
...
Рейтинг: 0 / 0
выбор IoC
    #38475976
Фотография Изопропил
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ViPRosкак я понял из базара, ДИ - это типа ресурс менеджера
не, это одна из функций, а основная - породить туеву хучу объектов, задать свойства, связи и так чтоб они не сами вытаскивали информацию о своей настройке, а снаружи некто(контейнер) их накормил
...
Рейтинг: 0 / 0
выбор IoC
    #38475979
ViPRos
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Изопропил,

ну я про это и грил, создать, запустить, вернуть,... кто во что горазд
в ВИПРОС это ОДИН метод
...
Рейтинг: 0 / 0
выбор IoC
    #38475980
ViPRos
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
и 12 таблиц :)
...
Рейтинг: 0 / 0
выбор IoC
    #38475981
Фотография Изопропил
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ViPRosи 12 таблиц :)
в spring.net - один XML файл
...
Рейтинг: 0 / 0
выбор IoC
    #38475985
ViPRos
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Изопропил,

и так можно, но много таблиц лучше :)
...
Рейтинг: 0 / 0
выбор IoC
    #38475995
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУПроблема в том, что эту именованную абстракцию области жизни как-то должен протащить в класс. Опять нагружать конструктор. Далее. Класс должен будет в нужный момент сказать, когда выгрузить именованную область. Что по сути те же яйца, что и обычный диспоуз сервиса. Прицнип тот же самый.

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

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

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

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

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

разница величиной в пропасть, не смотря на кажущееся родство обоих паттернов.
...
Рейтинг: 0 / 0
выбор IoC
    #38475996
Фотография Изопропил
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ViPRosи так можно, но много таблиц лучше :)
есть разные способы конфигурирования контейнеров - xml файлы, интерфейсы у которых контейнер запрашивает конфигурацию(можно и из таблиц данные взять), говнокод в конце концов, где привязка прибита гвоздями.
...
Рейтинг: 0 / 0
выбор IoC
    #38475999
Фотография Изопропил
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttбанальный пример
лучше небанальный с иерархией контекстов
...
Рейтинг: 0 / 0
выбор IoC
    #38476001
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУ,

кстати, Autofac, например, определяет свою фабрику зависимостей, которую можно прокидывать в класс, если он в момент создания ещё не уверен какая конкретно реализация зависимости ему понадобится:

Код: c#
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
public class SomeClass
{
   private readonly IIndex<sting, ISomeService service> _si;

   public SomeClass(IIndex<sting, ISomeService service> serviceIndex)
   {
      _si = serviceIndex;
   }

   public void SomeWork(string someName)
   {
      var service = _si[someName];
      ...
   }
}



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

проблемный класс:

Код: c#
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
public class SomeController
{
  private readonly IFirstService _firstService;
  private readonly ISecondService _secondService;
  private readonly IThirdService _thirdService;
  private readonly IFourthService _fourthService;

  public SomeController(
    IFirstService firstService,
    ISecondService secondService,
    IThirdService thirdService,
    IFourthService fourthService)
  {
    _firstService = firstService;
    _secondService = secondService;
    _thirdService = thirdService;
    _fourthService = fourthService;
  }
}



решение:

Код: c#
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
public interface IMyAggregateService
{
  IFirstService FirstService { get; }
  ISecondService SecondService { get; }
  IThirdService ThirdService { get; }
  IFourthService FourthService { get; }
}
public class SomeController
{
  private readonly IMyAggregateService _aggregateService;

  public SomeController(
    IMyAggregateService aggregateService)
  {
    _aggregateService = aggregateService;
  }
}



в общем, DI это достаточно гибкая хрень. я ещё сам до конца его не раскурил, но то что получается мне очень нравится. не серебряная пуля конечно, но очень удобно.
...
Рейтинг: 0 / 0
выбор IoC
    #38476003
ViPRos
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
что бы не говнокодить, надо писать сложные вещи, тогда найдешь собственные решения проблем
а так, да, надо изучить чужой опыт и применить по делу (если надо че то прибить гвоздем,то надо прибивать, а можно шурупы использовать если не дорого, иликакую нить съемную челюсть щоб легче было почистить в ванночке - ну разные у людей задачи)
...
Рейтинг: 0 / 0
выбор IoC
    #38476004
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ViPRosчто бы не говнокодить, надо писать сложные вещи, тогда найдешь собственные решения проблем
а так, да, надо изучить чужой опыт и применить по делу (если надо че то прибить гвоздем,то надо прибивать, а можно шурупы использовать если не дорого, иликакую нить съемную челюсть щоб легче было почистить в ванночке - ну разные у людей задачи)

опыт — это мудрость глупцов :)

можно набить свои индивидуальные шишки, а можно обойтись без этого, воспользовавшись чужим опытом. второе типа практичней.
...
Рейтинг: 0 / 0
выбор IoC
    #38476008
Фотография Изопропил
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ViPRosну разные у людей задачи)
ну и контейнеры бывают разные

Концепцию DI можно и без контейнера реализовать - главное обязанности разделить и лишними знаниями классы не обременять
...
Рейтинг: 0 / 0
выбор IoC
    #38476010
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttничего не надо тащить в класс кроме самой зависимости. всё по-фенщую. класс объявляет через конструктор и/или через открытые свойства о своих зависимостях. DI-контейнер эти зависимости разрешает. класс ничего не знает о каких-то там областей жизни в этом и соль. это понятие DI-контейнера. при чем это может и называть-ся совершенно иначе, и реализовано может быть по-другому.
Пример в студию. Мне нужно в конструкторе класса обратиться к сервису и прибить. После этого я могу в окне показать данные. Ждёмся.

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

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

разница величиной в пропасть, не смотря на кажущееся родство обоих паттернов.
Если в DependencyResolver нет управления жизнью, это еще не значит, что это локатор. Во-вторых, для веба его хватает за глаза. Для десктопа нужен контейнер посильнее.
...
Рейтинг: 0 / 0
выбор IoC
    #38476012
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУЯ же тебе давал ссылки. Практикуются, ибо это удобно. Во-вторых, не все DI контейнеры имеют именованные области жизни. В-третьих, намного проще освободить, чем делегировать освобождение. И самое главное - нету серебряной пули. Вот что я хочу, чтобы ты понял.

так чем ж проще самому диспозить? то ли это будет делать контейнер, то ли это будешь делать ты.

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


серебрянной пули нет. но мы же не об этом. я не ратую за то, что DI лучше или хуже чем что-либо другое. и что одно его применение сразу решит все проблемы. просто мне непонятна смесь DI + SL, как ты используешь. может это конечно и удобно...
...
Рейтинг: 0 / 0
выбор IoC
    #38476013
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttIMyAggregateService
Ну композитный класс это, конечно, выход. Но вглядит всё-равно стрёмно. Опять же, так и не увидел реальных причин, по которым "запрещено" протаскивать контейнер.
...
Рейтинг: 0 / 0
выбор IoC
    #38476014
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ИзопропилКонцепцию DI можно и без контейнера реализовать - главное обязанности разделить и лишними знаниями классы не обременять
Золотые слова.
...
Рейтинг: 0 / 0
выбор IoC
    #38476016
ViPRos
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttможно набить свои индивидуальные шишки, а можно обойтись без этого, воспользовавшись чужим опытом. второе типа практичней.
не всегда это так
вот ты я смотрю ты уже полгода с этим ДИ, СЛ трахаешься, и сам признал что все еще не до конца почувствовал оргазм
а если б жисть заставила изучать не ДИ СЛ а просто испытаь нормальный оргазм, ты б быстро нашел как это делается
а так все эти паттерны ведут к одной скрытой цели - ты пишеь предложение на каком нить чукчинсом языке и - начинается
парсеры, онтологии, тезаурусы, грамматики... и вот сгенерирован внутренний запрос и отправлен в сеть для поиска соответствия, разрешения, генерации ответа ...
если цель ясна, то дорога видна
...
Рейтинг: 0 / 0
выбор IoC
    #38476017
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУПример в студию. Мне нужно в конструкторе класса обратиться к сервису и прибить. После этого я могу в окне показать данные. Ждёмся.

МСУВопросы появляются, когда в конкретном месте мне нужен диспоуз.

блин кому нужно? классу или сервису?

вот это убъёт зависимость сразу же, как убъёт класс:

builder.RegisterType<X>().InstancePerDependency();
...
Рейтинг: 0 / 0
выбор IoC
    #38476020
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУОпять же, так и не увидел реальных причин, по которым "запрещено" протаскивать контейнер.

жесткая зависимость от контейнера. мало? потеря контроля за выдачей экземпляров. вместо автоматического разрешения зависимостей, мануальная терапия. есть ли в этом такая необходимость?
...
Рейтинг: 0 / 0
выбор IoC
    #38476022
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttМСУЯ же тебе давал ссылки. Практикуются, ибо это удобно. Во-вторых, не все DI контейнеры имеют именованные области жизни. В-третьих, намного проще освободить, чем делегировать освобождение. И самое главное - нету серебряной пули. Вот что я хочу, чтобы ты понял.

так чем ж проще самому диспозить? то ли это будет делать контейнер, то ли это будешь делать ты.

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


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

Давай еще раз. Вот мой класс - вью модель в WPF, в которую я протаскиваю контейнер и радуюсь жизни: [

Код: c#
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
public class EmployeesViewModel : ViewModelBase
{
    private IWindowService WinService;

    public EmployeesViewModel(IUnityContainer container)
    {
        WinService = container.Resolve<IWindowService>();        
        Context = container.Resolve<IDataContext>();
        
        Context.GetData()... // обращение к сервису, что-то делаем
        Context.Dispose();
    }
}



Сделай мне тоже самое с помощью своим управлением жизни. Еще раз подчеркну: очень важно, чтобы диспоуз был сразу после вызова метода GetData().
...
Рейтинг: 0 / 0
выбор IoC
    #38476023
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttМСУПример в студию. Мне нужно в конструкторе класса обратиться к сервису и прибить. После этого я могу в окне показать данные. Ждёмся.

МСУВопросы появляются, когда в конкретном месте мне нужен диспоуз.

блин кому нужно? классу или сервису?

вот это убъёт зависимость сразу же, как убъёт класс:

builder.RegisterType<X>().InstancePerDependency();

Я же сказал, не катит. Класс должен жить. Выше я дал пример.
...
Рейтинг: 0 / 0
выбор IoC
    #38476024
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttМСУОпять же, так и не увидел реальных причин, по которым "запрещено" протаскивать контейнер.

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

Я готов зависеть от контейнера. Контроль выдачи не теряется, ты о чем?
...
Рейтинг: 0 / 0
выбор IoC
    #38476027
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУ,

Код: c#
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
public class EmployeesViewModel : ViewModelBase
{
    private IWindowService WinService;

    public EmployeesViewModel(IWindowService windowService, IDataContext context)
    {
        WinService = windowService;        
        Context = context;
        
        Context.GetData()... // обращение к сервису, что-то делаем
///         Context.Dispose(); // NO!
    }
}



вообще, вью-модель не должна сама получать данные из контекста. поэтому у тебя такая хрень. я бы убрал зависимость от IDataContext из вью-модели. это неправильно если ты делаешь MVC/MVP.
...
Рейтинг: 0 / 0
выбор IoC
    #38476028
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУЯ готов зависеть от контейнера. Контроль выдачи не теряется, ты о чем?

ну если признать это за аксиому, мои доводы все до единого бессмысленны.

я не готов зависеть от контейнера. я хочу иметь возможность малой кровью отделаться от Autofac и перейти на Unity, или на Ninject. я хочу управлять зависимостями в одном месте. исопльзовать модульную композицию.

именно поэтому я никогда не использую DependencyResolver. за ненадобностью. у каждого класса своя маленькая область ответственности. он выполняет всего лишь свою задачку и никуда больше не лезет. поэтмоу в моём проекте не существует классов с десятками зависимостей. не больше 1-3 зависимостей.
...
Рейтинг: 0 / 0
выбор IoC
    #38476034
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttМСУ,

Код: c#
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
public class EmployeesViewModel : ViewModelBase
{
    private IWindowService WinService;

    public EmployeesViewModel(IWindowService windowService, IDataContext context)
    {
        WinService = windowService;        
        Context = context;
        
        Context.GetData()... // обращение к сервису, что-то делаем
///         Context.Dispose(); // NO!
    }
}



вообще, вью-модель не должна сама получать данные из контекста. поэтому у тебя такая хрень. я бы убрал зависимость от IDataContext из вью-модели. это неправильно если ты делаешь MVC/MVP.

1. Мне нужен диспоуз после GetData. Где решение?
2. Я уточнил - это WPF, паттерн MVVM. Это не MVC и не MVP. Тут вью-модель может обращаться к сервисам, тут есть dual mode байдинги, тут много что есть. MVC этого и не снилось. Ну ладно, это всё философия.

Где решение???
...
Рейтинг: 0 / 0
выбор IoC
    #38476035
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttМСУЯ готов зависеть от контейнера. Контроль выдачи не теряется, ты о чем?
ну если признать это за аксиому, мои доводы все до единого бессмысленны.
А в чем проблема зависимости от контейнера? Ну ладно, допустим я буду в ViewModel подавать сервисы, хрен с тобой. Но мне всё-равно нужно отдиспоузить сервис после GetData. Где решение?
...
Рейтинг: 0 / 0
выбор IoC
    #38476036
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttвообще, вью-модель не должна сама получать данные из контекста.
А вообще сразу невооруженным глазом видно, про MVVM не слыхал :)
...
Рейтинг: 0 / 0
выбор IoC
    #38476037
Фотография Где-то в степи
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУ, авторМне нужен диспоуз после GetData. Где решение?
раскомментируй ///
Вообще то что ты пытаешься прикрутить диспоус к di это круто, то о чем много говорят ( о жизни объекта) как бы к самой жизни его
как объекта ( в понимании расхода памяти и ресурсов ядра) не имеет вообще отношения, это банальный кеш а вот время кеша
и определяем этими терминами, вообще то объект может и не иметь механизма освобождения ресурсов.. хочешь диспозить - диспозь в ручную,
...
Рейтинг: 0 / 0
выбор IoC
    #38476039
SeVa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУhVosttМСУ,

Код: c#
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
public class EmployeesViewModel : ViewModelBase
{
    private IWindowService WinService;

    public EmployeesViewModel(IWindowService windowService, IDataContext context)
    {
        WinService = windowService;        
        Context = context;
        
        Context.GetData()... // обращение к сервису, что-то делаем
///         Context.Dispose(); // NO!
    }
}




вообще, вью-модель не должна сама получать данные из контекста. поэтому у тебя такая хрень. я бы убрал зависимость от IDataContext из вью-модели. это неправильно если ты делаешь MVC/MVP.

1. Мне нужен диспоуз после GetData. Где решение?
2. Я уточнил - это WPF, паттерн MVVM. Это не MVC и не MVP. Тут вью-модель может обращаться к сервисам, тут есть dual mode байдинги, тут много что есть. MVC этого и не снилось. Ну ладно, это всё философия.

Где решение???

Муслима, грузить данные в конструкторе - полный маразм и блокировка экрана.
Решение простое - сервис навигации и асинхронная загрузка данных, те нормальный фреймворк, а не пионерский бред.
Твое понимание mvvm совершенно тупое - навесить на него все и вся(навигацию, валидацию, DAL, еtc), те довести до неудобоваримого состояния.
...
Рейтинг: 0 / 0
выбор IoC
    #38476043
Фотография Изопропил
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Где-то в степихочешь диспозить - диспозь в ручную,
контейнеру предварительно имеет смысл сообщить, что временем жизни собирается управлять клиент - и никаких проблем
...
Рейтинг: 0 / 0
выбор IoC
    #38476049
SeVa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Если в ГовноДатаСервисе необходим режим per-call, то он должен сам закрывать неуправляемые ресурсы (соединение с БД, wcf proxy) и ничего тогда диспозить не нужно. net прекрасно все уберет сам.
...
Рейтинг: 0 / 0
выбор IoC
    #38476051
Фотография Где-то в степи
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Изопропил,
время жизни, это время жизни, а использование уже созданного объекта - тут я не знаю, подойдет ли этот термин для
того о чем говорим.
вот предположим, определили мы объект с параметром ContainerControlledLifetimeManager по существу синглтон для созданого
контейнера, или еще как ну для контекста запроса. или для потока, дак ты его задиспоз до дыр он никуда не исчезнет
пока на него ссылка будет указываться в контейнере, потом да, при определенных условиях он отдиспозится как надо, и
исключение что обратились к уничтоженному объекту не сгенерится, ибо ссылка на него живее всех живых - на время кеша.
ресурсы ядра - да освободятся, а коллектор его не приберет, вообще лично мне не нравится вот эта вся банальщина
вот пример реализации

Код: c#
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
  public class ContainerControlledLifetimeManager : SynchronizedLifetimeManager, IDisposable
    {
        private object value;

        /// <summary>
        /// Retrieve a value from the backing store associated with this Lifetime policy.
        /// </summary>
        /// <returns>the object desired, or null if no such object is currently stored.</returns>
        protected override object SynchronizedGetValue()
        {
            return value;
        }

        /// <summary>
        /// Stores the given value into backing store for retrieval later.
        /// </summary>
        /// <param name="newValue">The object being stored.</param>
        protected override void SynchronizedSetValue(object newValue)
        {
            value = newValue;
        }

        /// <summary>
        /// Remove the given object from backing store.
        /// </summary>
        public override void RemoveValue()
        {
            Dispose();
        }

        ///<summary>
        ///Performs application-defined tasks associated with freeing, releasing, or resetting unmanaged resources.
        ///</summary>
        ///<filterpriority>2</filterpriority>
        public void Dispose()
        {
            Dispose(true);
        }

        /// <summary>
        /// Standard Dispose pattern implementation. Not needed, but it keeps FxCop happy.
        /// </summary>
        /// <param name="disposing">Always true, since we don't have a finalizer.</param>
        // FxCop suppression: This method is only here to avoid the other IDisposable warning.
             protected void Dispose(bool disposing)
        {
            if (value != null)
            {
                if (value is IDisposable)
                {
                    ((IDisposable) value).Dispose();
                }
                value = null;
            }
        }
    }


...
Рейтинг: 0 / 0
выбор IoC
    #38476052
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SeVaМСУпропущено...


1. Мне нужен диспоуз после GetData. Где решение?
2. Я уточнил - это WPF, паттерн MVVM. Это не MVC и не MVP. Тут вью-модель может обращаться к сервисам, тут есть dual mode байдинги, тут много что есть. MVC этого и не снилось. Ну ладно, это всё философия.

Где решение???

Муслима, грузить данные в конструкторе - полный маразм и блокировка экрана.
Решение простое - сервис навигации и асинхронная загрузка данных, те нормальный фреймворк, а не пионерский бред.
Твое понимание mvvm совершенно тупое - навесить на него все и вся(навигацию, валидацию, DAL, еtc), те довести до неудобоваримого состояния.
Дурилка, маразм у тебя в башке, а не в конструкторе. Никакой блокировки экрана не будет, будут доступны все формы, кроме той, которая тормозит. Это не сильверлайт с одним окном в браузере. Городить асинхроннын окна тут смысла не имеет. Твое понимание дотнета поверхностное и ограниченное. В конструкторе - инициализация данных. После загрузки окна возможны снова обращения к сервисам.
...
Рейтинг: 0 / 0
выбор IoC
    #38476055
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ИзопропилГде-то в степихочешь диспозить - диспозь в ручную,
контейнеру предварительно имеет смысл сообщить, что временем жизни собирается управлять клиент - и никаких проблем
В юнити даже life time режим такой есть. Это нормальная практика.
...
Рейтинг: 0 / 0
выбор IoC
    #38476057
Фотография Где-то в степи
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SeVa,
вообщето можно в ручную диспозить, никто не запрещает, если при разрушении хранилища кеша. возникнет повторный диспоз
да и хрен с ним, паттерн это допускает, наворотили понимаишь(с), я не удивлюсь если ди в пятом поколении миньет будут делать..
...
Рейтинг: 0 / 0
выбор IoC
    #38476059
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Без мягкого знака, Жень.
...
Рейтинг: 0 / 0
выбор IoC
    #38476061
Фотография Где-то в степи
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУ,

Спасибо
...
Рейтинг: 0 / 0
выбор IoC
    #38476070
SeVa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУSeVaпропущено...


Муслима, грузить данные в конструкторе - полный маразм и блокировка экрана.
Решение простое - сервис навигации и асинхронная загрузка данных, те нормальный фреймворк, а не пионерский бред.
Твое понимание mvvm совершенно тупое - навесить на него все и вся(навигацию, валидацию, DAL, еtc), те довести до неудобоваримого состояния.
Дурилка, маразм у тебя в башке, а не в конструкторе. Никакой блокировки экрана не будет, будут доступны все формы, кроме той, которая тормозит. Это не сильверлайт с одним окном в браузере. Городить асинхроннын окна тут смысла не имеет. Твое понимание дотнета поверхностное и ограниченное. В конструкторе - инициализация данных. После загрузки окна возможны снова обращения к сервисам.

Муслима, нельзя быть немножко беременным. Если одна форма тормозит(а в твоем говноокносервисе унылый mdi), то тормозит все. А sl не пачкай своими потными, дрочливыми ручонками, там изначально заложена асинхронность именно на этот случай, чтобы тупой рукоблуд не морозил все.
Чтобы данные грузились после загрузки окна - это непосильная для тебя задача.
Ты способен только на это говно
Код: c#
1.
2.
3.
4.
5.
6.
7.
8.
9.
public bool OpenEmployeeDetailWindow(Employee employee)
        {
            var view = new EmployeeDetailWindow();
            view.Owner = ActiveWindow;
            view.DataContext = new EmployeeViewModel { EmployeeId = employee.EmployeeId, FirstName = employee.FirstName, LastName = employee.LastName };

// три часа ждем, а потом показываем окно. пользовать уже заснул.
            return view.ShowDialog().GetValueOrDefault();
        }
...
Рейтинг: 0 / 0
выбор IoC
    #38476082
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУ1. Мне нужен диспоуз после GetData. Где решение?
2. Я уточнил - это WPF, паттерн MVVM. Это не MVC и не MVP. Тут вью-модель может обращаться к сервисам, тут есть dual mode байдинги, тут много что есть. MVC этого и не снилось. Ну ладно, это всё философия.

Где решение???

то о чём ты говоришь, называется Unit Of Work.

пжалста:

Код: c#
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
public class EmployeesViewModel : ViewModelBase
{
    private IWindowService WinService;

    public EmployeesViewModel(IWindowService windowService, Owned<IDataContext> context)
    {
        WinService = windowService;        
///         Context = context;  /// -- Нахуа тогда вот это нужно, если ты его сразу диспозишь???
        
        context.Value.GetData()... // обращение к сервису, что-то делаем
        context.Dispose(); // OK
    }
}



Owned<T> -- это Unit Of Work контейнер. говорит как бы само за себя.

можно ещё круче, генерация и уничтожение экземпляров под управлением DI, на лету:

Код: c#
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
interface IMessageHandler
{
    void Handle(Message message);
}

class MessagePump
{
    Func<Owned<IMessageHandler>> _handlerFactory;
    
    public MessagePump(Func<Owned<IMessageHandler>> handlerFactory)
    {
        _handlerFactory = handlerFactory;
    }
    
    public void Go()
    {
        while(true)
        {
            var message = NextMessage();
            
            using (var handler = _handlerFactory())
            {
                handler.Value.Handle(message);
            }
        } 
    }
}



Какие-проблемы-то? я конечно склоняюсь к тому, что архитектурка тобою приведённая довольно таки хреновая, ибо что-то осмысленное в конструкторе делать -- моветон. нельзя. такие вещи надо поручать фабрикам и (в случае MVVM), диспетчеру. но никак не жётко хардкодить.
...
Рейтинг: 0 / 0
выбор IoC
    #38476085
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУ,

и ещё

Код: c#
1.
private IWindowService WinService;



решарпера на тебя нет!
...
Рейтинг: 0 / 0
выбор IoC
    #38476089
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Где-то в степивообщето можно в ручную диспозить, никто не запрещает, если при разрушении хранилища кеша. возникнет повторный диспоз
да и хрен с ним, паттерн это допускает, наворотили понимаишь(с), я не удивлюсь если ди в пятом поколении миньет будут делать..

проблема не в повторном диспозе. а в возможном обращении к трупу. на счёт способностей современных DI ты прав, эти черти позволяют очень много, уже давно выходящее за рамки изначального описания основ принципа паттерна. это хорошо.
...
Рейтинг: 0 / 0
выбор IoC
    #38476094
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MVVM-щикам в обязательном порядке читать Unit of Work in Rich Clients для понимания сути вселенной. ну и чтобы не пороть горячку с передачей контейнера вглубь классов, как будто сигареты без фильтра каким-нибудь заключённым на зону.

а вот полезная приблуда для профайлинга IoC (autofac), возможных проблем связанных с неправильным управлением времени жизни.
...
Рейтинг: 0 / 0
выбор IoC
    #38476139
Фотография Где-то в степи
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVostt,
авторпроблема не в повторном диспозе. а в возможном обращении к трупу. вот вот я еще и должен постоянно лазить
в регистрацию и смотреть какой кеш я заказал для объекта, мне все эти плюшки напоминают наличие критериев в хибере при живом
куерилабле, кому как, а мне легче написать свой di с инжекцией чем тащить этот велосипед с катафотами и брызговиками - может от того что он легко пишется в сети столько реализаций этой фишки, такое ощущение что только ленивый не приложил к нему руку,
и как правило в стиле рыночной экономики - пользуйтесь наш может то то и то то - что не могут другие..
...
Рейтинг: 0 / 0
выбор IoC
    #38476178
SeVa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Где-то в степиhVostt,
авторпроблема не в повторном диспозе. а в возможном обращении к трупу. вот вот я еще и должен постоянно лазить
в регистрацию и смотреть какой кеш я заказал для объекта, мне все эти плюшки напоминают наличие критериев в хибере при живом
куерилабле, кому как, а мне легче написать свой di с инжекцией чем тащить этот велосипед с катафотами и брызговиками - может от того что он легко пишется в сети столько реализаций этой фишки, такое ощущение что только ленивый не приложил к нему руку,
и как правило в стиле рыночной экономики - пользуйтесь наш может то то и то то - что не могут другие..

Dispose нужен только MCУ, чтобы дернуть за ручку унитаза и смыть свои отложения.
Возможность явно вызвать dispose появилась только в третьей версии, а до этого все жили без этого,
в нем все на слабых ссылках и сборщик памяти все спокойно убирал.
Общий контекст выполнения нужен только для того, чтобы не создавать одно и тоже сорок восемь раз во время бизнес-транзакции.
В WPF у контролов вообще нет dispose, тк это управляемые ресурсы.
...
Рейтинг: 0 / 0
выбор IoC
    #38476204
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SeVaМуслима, нельзя быть немножко беременным. Если одна форма тормозит(а в твоем говноокносервисе унылый mdi), то тормозит все. А sl не пачкай своими потными, дрочливыми ручонками, там изначально заложена асинхронность именно на этот случай, чтобы тупой рукоблуд не морозил все.
Дуралейка, нельзя быть немного идиотом - нет никакого MDI. Есть главное окно (Owner) и его дочерние окна. Если какое-то дочернее окно тормозит, это никак не влияет на работу всего остального. Опять ты глупости пишешь.

SeVaЧтобы данные грузились после загрузки окна - это непосильная для тебя задача.
Дурик, тебе твой сильверлайт окончательно снес башку. Задача уровня детского сада, но ты так гордишься, что кое как со скрипом осилил DispatcherSynchronizationContext.
...
Рейтинг: 0 / 0
выбор IoC
    #38476206
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttМСУ1. Мне нужен диспоуз после GetData. Где решение?
2. Я уточнил - это WPF, паттерн MVVM. Это не MVC и не MVP. Тут вью-модель может обращаться к сервисам, тут есть dual mode байдинги, тут много что есть. MVC этого и не снилось. Ну ладно, это всё философия.

Где решение???

то о чём ты говоришь, называется Unit Of Work.

пжалста:

Код: c#
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
public class EmployeesViewModel : ViewModelBase
{
    private IWindowService WinService;

    public EmployeesViewModel(IWindowService windowService, Owned<IDataContext> context)
    {
        WinService = windowService;        
///         Context = context;  /// -- Нахуа тогда вот это нужно, если ты его сразу диспозишь???
        
        context.Value.GetData()... // обращение к сервису, что-то делаем
        context.Dispose(); // OK
    }
}



Owned<T> -- это Unit Of Work контейнер. говорит как бы само за себя.

можно ещё круче, генерация и уничтожение экземпляров под управлением DI, на лету:

Код: c#
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
interface IMessageHandler
{
    void Handle(Message message);
}

class MessagePump
{
    Func<Owned<IMessageHandler>> _handlerFactory;
    
    public MessagePump(Func<Owned<IMessageHandler>> handlerFactory)
    {
        _handlerFactory = handlerFactory;
    }
    
    public void Go()
    {
        while(true)
        {
            var message = NextMessage();
            
            using (var handler = _handlerFactory())
            {
                handler.Value.Handle(message);
            }
        } 
    }
}



Какие-проблемы-то? я конечно склоняюсь к тому, что архитектурка тобою приведённая довольно таки хреновая, ибо что-то осмысленное в конструкторе делать -- моветон. нельзя. такие вещи надо поручать фабрикам и (в случае MVVM), диспетчеру. но никак не жётко хардкодить.

Ты сам себе противоречишь. Сначала никаких Dispose из ViewModel, то теперь отжигаешь. Как понимать?

В чем тут хреновая архитектура, можешь внятно объяснить? Сначала ты пишешь, что нельзя вызывать сервисы из вью модели (по неопытности). Потом ты пишешь откровенный диспоуз в ней. Потом ты пишешь какую-то чушь про хреновую архитектуру. Извини, но у меня складывается ощущение, что ты полный ноль в обсуждаемой теме. Кроме веб приложений на мвц далече не сувался.
...
Рейтинг: 0 / 0
выбор IoC
    #38476208
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttМСУ,

и ещё

Код: c#
1.
private IWindowService WinService;



решарпера на тебя нет!

Не вижу повода для паники. Или опять вбитый гвоздями шаблон не дает покоя?
...
Рейтинг: 0 / 0
выбор IoC
    #38476234
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Хвост, вот тебе еще железобетонный пример, когда нужно передавать контейнер в класс, а не сервис.

Всё та же вью модель для WPF приложения.

1. При открытии окна идет обращение к сервису, получаем данные (переменная history), диспоузим сервис, наполняем наблюдаемую коллекцию (байдинг на дата грид в XAML).

2. Через какое-то время мы из этого окна захотим получить отчет, то есть опять обратиться к сервису, который мы ранее убили (команда OpenReportCommand, байдинг на клик кнопки). Но так как у нас в конструктор ходит контейнер, мы без проблем снова резолвим сервис данных, вызываем метод GetEmployees, диспоузим сервис. Передаем готовые данные в метод формирования отчета.

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

Код: c#
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
public class MainViewModel: ViewModelBase
{
    private IUnityContainer Container;

    public MainViewModel(IUnityContainer container)
    {
        Container = container;

        var ctx = Container.Resolve<IDataContext>();
        var history = ctx.GetHistory();
        ctx.Dispose();

        History = new ObservableCollection<History>(history);
    }

    public IIdentity Identity { get { return WindowsIdentity.GetCurrent(); } }

    private ObservableCollection<History> _history;
    public ObservableCollection<History> History
    {
        get
        {
            return _history;
        }
        set
        {
            _history = value;
            OnPropertyChanged(() => History);
        }
    }

    private ICommand _openReportCommand;
    public ICommand OpenReportCommand
    {
        get
        {
            if (_openReportCommand == null)
            {
                _openReportCommand = new RelayCommand(action => 
                {
                    var ctx = Container.Resolve<IDataContext>();
                    var employees = ctx.GetEmployees();
                    ctx.Dispose();

                    Container.Resolve<IWindowService>().OpenReport(employees); 
                });
            }

            return _openReportCommand;
        }
    }       
}
...
Рейтинг: 0 / 0
выбор IoC
    #38476236
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
А тот гавнокод, что ты привёл со своим "MessagePump" не поддается даже здравой логике. Это полный алес капут.
...
Рейтинг: 0 / 0
выбор IoC
    #38476301
Фотография Нахлобуч
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУ
Надо правильные контейнеры использовать:
Код: c#
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
public class MainViewModel : ViewModelBase
{
    public Func<IDataContext> DataContextProvider { get; set; }    

    public MainViewModel()
    {
        History history;
        using(var ctx = DataContextProvider())
            history = ctx.GetHistory();        

        History = new ObservableCollection<History>(history);
    }
}
...
Рейтинг: 0 / 0
выбор IoC
    #38476303
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУТы сам себе противоречишь. Сначала никаких Dispose из ViewModel, то теперь отжигаешь. Как понимать?

а никаких Dispose контекста и нет. если ты это не доходит. то всё. алес. умываю руки.
...
Рейтинг: 0 / 0
выбор IoC
    #38476306
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУПотом ты пишешь откровенный диспоуз в ней. Потом ты пишешь какую-то чушь про хреновую архитектуру. Извини, но у меня складывается ощущение, что ты полный ноль в обсуждаемой теме. Кроме веб приложений на мвц далече не сувался.

мдя... чувак. можно закрывать тему. ты свой уровень прекрасно показал. не можешь различить диспоуз сервиса и диспоуз UOW (который всего лишь указывает DI контейнеру, что Owner больше не нужен).

не ебай мне мозги. давай заканчивать бесполезный треп. я вижу что ты окончательно не одупляешься.
...
Рейтинг: 0 / 0
выбор IoC
    #38476308
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУА тот гавнокод, что ты привёл со своим "MessagePump" не поддается даже здравой логике. Это полный алес капут.

дооооооооооо. напишу авторам autofac что они говнокодеры. пусть придут поучатся у великого МСУ.

ну и посмешил же ты меня. не собираюсь больше убивать на тебя время. ты не прошибаемый. лишь бы не признать что не прав. да оставайся при своём мнении. мне как-то уже пофиг.
...
Рейтинг: 0 / 0
выбор IoC
    #38476312
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Код: c#
1.
2.
3.
4.
5.
public class MainViewModel: ViewModelBase
{
    private IUnityContainer Container;

    public MainViewModel(IUnityContainer container)



особенно доставило. МСУ. ты и правда ВОТ ТАК ПИШЕШЬ? ЭТО куски кода из реального проекта?
...
Рейтинг: 0 / 0
выбор IoC
    #38476315
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУСначала ты пишешь, что нельзя вызывать сервисы из вью модели (по неопытности).

вообщето только по неопытность можно засунуть добычу данных из сервиса в конструкторе. простительно первокласснику. но не опытному программисту. надо пересмотреть его квалификации и спросит, хуле он в программировании забыл.
...
Рейтинг: 0 / 0
выбор IoC
    #38476325
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttМСУТы сам себе противоречишь. Сначала никаких Dispose из ViewModel, то теперь отжигаешь. Как понимать?

а никаких Dispose контекста и нет. если ты это не доходит. то всё. алес. умываю руки.

Как нет, если есть? 15183035

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

hVosttМСУПотом ты пишешь откровенный диспоуз в ней. Потом ты пишешь какую-то чушь про хреновую архитектуру. Извини, но у меня складывается ощущение, что ты полный ноль в обсуждаемой теме. Кроме веб приложений на мвц далече не сувался.

мдя... чувак. можно закрывать тему. ты свой уровень прекрасно показал. не можешь различить диспоуз сервиса и диспоуз UOW (который всего лишь указывает DI контейнеру, что Owner больше не нужен).

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

Хвост, твой уровень и так всем понятен. Понахватался вершков с хабров и веришь в свой шаблон, молясь на него как на икону. А задача не решена. Пытаешься всё больше и больше нагрузить свой гавнокод левыми педалями, а не выходит каменный цветок. Где решение? Нету решения. Потому что узко смотришь на мир из-под призмы mvc. Твои студенческие взгляды - юношеский максимализм на пустом месте.
...
Рейтинг: 0 / 0
выбор IoC
    #38476329
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttМСУА тот гавнокод, что ты привёл со своим "MessagePump" не поддается даже здравой логике. Это полный алес капут.

дооооооооооо. напишу авторам autofac что они говнокодеры. пусть придут поучатся у великого МСУ.

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

Да, напиши еще авторам Unity, пусть поучатся у твоих автофаковых авторов. Где конечно решение? Тебе не надоело скакать как белка в колесе?
...
Рейтинг: 0 / 0
выбор IoC
    #38476330
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVostt
Код: c#
1.
2.
3.
4.
5.
public class MainViewModel: ViewModelBase
{
    private IUnityContainer Container;

    public MainViewModel(IUnityContainer container)



особенно доставило. МСУ. ты и правда ВОТ ТАК ПИШЕШЬ? ЭТО куски кода из реального проекта?

Да, я так пишу. Что тебя смущает? Очередной шаблон в башке застрял?
...
Рейтинг: 0 / 0
выбор IoC
    #38476332
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttМСУСначала ты пишешь, что нельзя вызывать сервисы из вью модели (по неопытности).

вообщето только по неопытность можно засунуть добычу данных из сервиса в конструкторе. простительно первокласснику. но не опытному программисту. надо пересмотреть его квалификации и спросит, хуле он в программировании забыл.

Одно слюнометание, а по делу ноль. Конструктор - это какой-то запрещенный метод? Или ты боишься конструкторов? А задача так и не решена...
...
Рейтинг: 0 / 0
выбор IoC
    #38476335
Фотография Изопропил
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУ,

Обустройство конструктора - это предмет для отдельного срача
...
Рейтинг: 0 / 0
выбор IoC
    #38476338
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ИзопропилМСУ, Обустройство конструктора - это предмет для отдельного срача
Хвост еще не дорос до уровня срача о конструкторах, слишком низко плавает. Он только вчера узнал, что вью модель может дергать сервисы и лямбда компилируется в делегат. А ты такое предлагаешь.
...
Рейтинг: 0 / 0
выбор IoC
    #38476339
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Изопропил, одни его отжиги, что ООП - УГ, а наследование для ламеров, заслуживают посадки на кол. Ну это ладно, будет с ним.
...
Рейтинг: 0 / 0
выбор IoC
    #38476340
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУИзопропил, одни его отжиги, что ООП - УГ, а наследование для ламеров, заслуживают посадки на кол. Ну это ладно, будет с ним.
Попахивает севиной шизофренией о том, что IPrincipal круче мембершипа
...
Рейтинг: 0 / 0
выбор IoC
    #38476347
ShSerge
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Модератор: Сритесь без переходов, так сказать.
...
Рейтинг: 0 / 0
выбор IoC
    #38476351
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Серж, прикрыл бы ты тему до пятницы, работать надо. Но и посраться хочется, Хвосту ж нужно пендалей навесить для профилактики
...
Рейтинг: 0 / 0
выбор IoC
    #38476356
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУНо и посраться хочется, Хвосту ж нужно пендалей навесить для профилактики

прежде чем пендалей навешивать, отрасти пендальку )) я твою задачу выполнил. сообщил DI контейнеру когда IDataContext больше не нужен. ты включил дибила. что я могу тут сделать. мозги тебе купить?
...
Рейтинг: 0 / 0
выбор IoC
    #38476359
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУХвост еще не дорос до уровня срача о конструкторах, слишком низко плавает.

да уж. вот пробрасывать контейнер вглубь классов это высший пелотаж. не смеши мои тапочки. такое УГ даже у студентов ещё поискать надо.
...
Рейтинг: 0 / 0
выбор IoC
    #38476360
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУА задача так и не решена...

задача решена. глаза разуй.
...
Рейтинг: 0 / 0
выбор IoC
    #38476365
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУООП - УГ, а наследование для ламеров, заслуживают посадки на кол. Ну это ладно, будет с ним.

выдумщик.
...
Рейтинг: 0 / 0
выбор IoC
    #38476368
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ИзопропилОбустройство конструктора - это предмет для отдельного срача

какой смысл в сраче. Рихтер уже не в одном поколении книжек пишет, не выполняйте значимую работу в конструкторах. цель конструктора -- сконструировать объект. но можно сказать. пошёл в ж. этот Рихтер и еже сним. говнокодю как хочу и никто мне не указ. ишь! шаблонное мышлене нам пропихивают.
...
Рейтинг: 0 / 0
286 сообщений из 286, показаны все 12 страниц
Форумы / ASP.NET [игнор отключен] [закрыт для гостей] / выбор IoC
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]