powered by simpleCommunicator - 2.0.59     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / ASP.NET [игнор отключен] [закрыт для гостей] / комисарское тело di
41 сообщений из 41, показаны все 2 страниц
комисарское тело di
    #38477380
Фотография Где-то в степи
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
по поводу трехдневного срача по di
оставив за бортом тему sl или di
хочу ( и призываю вас подвести резюме) по поводу освобождения ресурсов через di.
так как реализаций ди очень много порядка 180 - 200 штук в топе только порядка десятки, стоит рассмотреть
это на примере 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.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
namespace Microsoft.Practices.Unity
{
    /// <summary>
    /// A <see cref="LifetimeManager"/> that holds onto the instance given to it.
    /// When the <see cref="ContainerControlledLifetimeManager"/> is disposed,
    /// the instance is disposed with it.
    /// </summary>
    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);
            GC.SuppressFinalize(this); // shut FxCop up
        }

        /// <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.
        [SuppressMessage("Microsoft.Usage", "CA1801:ReviewUnusedParameters", MessageId = "disposing")]
        protected void Dispose(bool disposing)
        {
            if (value != null)
            {
                if (value is IDisposable)
                {
                    ((IDisposable) value).Dispose();
                }
                value = null;
            }
        }
    }
}


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

Код: 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.
  public class TransientLifetimeManager : LifetimeManager
    {
        /// <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>
        public override object GetValue()
        {
            return null;
        }

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

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


Так стоит или не стоит рукоблудить, конечно стоит, работайте в своей парадигме как и раньше, Диспозьте по надобности,
тут дело вот в чем:
1 сам паттерн допускает многократное повторение операции.

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


чего стоит опасаться:
1 если объект захвачен контейнером, при повторном вызове уже освобожденного объекта - можно нарваться на инвалида.
2 если вы запустите объект куда нибудь за облака а потом его отдеспоузите через контейнер - то за облаками будет null.


ну и про сам контейнер, не велика птица протаскивать его через конструктор, делаем закрытый от всех контейнер, а наружу выставляем IUnityContainer через CreateChildContainer(), т.е. контейнер дитя - контракт на одноразовую работу, потом по надобности прибиваем..
сам никогда этой штуковиной не пользовался - дополняйте....
Просьба не сильно с...ть, охотник по пятам, уже два топика накрыл...
...
Рейтинг: 0 / 0
комисарское тело di
    #38477391
Фотография Изопропил
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Где-то в степит.е. контейнер дитя - контракт на одноразовую работу, потом по надобности прибиваем..
нормальный ход
...
Рейтинг: 0 / 0
комисарское тело di
    #38477394
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Не, я придерживаюсь идеологии статичности контейнера. Доступен на протяжении жизни апп домена.
...
Рейтинг: 0 / 0
комисарское тело di
    #38477396
Фотография Где-то в степи
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУ,
да пускай так будет, делаешь статический. регистрируешь типы, и от него получаешь детей для работы, а как ты хотел в статическом -одно на все приложение освобождать объекты которые захвачены - в конце приложения?, получается они все время жизни приложения там таскаться будут?
...
Рейтинг: 0 / 0
комисарское тело di
    #38477405
Фотография Где-то в степи
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУ,
примерно так через nuget расширить можно
Код: 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.
public static class Bootstrapper
    {
        public static IUnityContainer UnityContainer
        {
            get
            {
                return _container.CreateChildContainer();
            }
        }
        private static IUnityContainer _container;
       

        public static void Initialise()
        {
             _container = BuildUnityContainer();

            DependencyResolver.SetResolver(new UnityDependencyResolver(_container));
        }

         static IUnityContainer BuildUnityContainer()
        {
            var container = new UnityContainer();

            // register all your components with the container here
            // it is NOT necessary to register your controllers
            
            // e.g. container.RegisterType<ITestService, TestService>();            

           
           
            return container;
        }
    }
...
Рейтинг: 0 / 0
комисарское тело di
    #38477408
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Где-то в степи, не понял вопроса. В конце приложения будет выгрузка домена, можно даже не заморачиваться о диспоузе managed объектов. Во-вторых, статический контейнер вполне себе резолвит сервисы в соответствии с их заданными life time. То есть диспосабельные сервисы ты дестроишь сам по месту. В mvc я их дестрою автоматом в базовом контроллере, все сервисы там ленивые, разумеется.
...
Рейтинг: 0 / 0
комисарское тело di
    #38477411
Фотография Где-то в степи
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУ,
да ради бога, если все в елочку, кто запрещает, тем более там все захваты монитором лочатся, но очевидный путь для меня через детей, тем более при желании можно исполнять с ними разные кренделя с регистрацией, и легко убивать, не затрагивая контейнер папу..
...
Рейтинг: 0 / 0
комисарское тело di
    #38477414
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
вы как будто намеряно игнорируете UOW. не сложилось чтоле?
об этом элегантном паттерне только ленивый не написал...
...
Рейтинг: 0 / 0
комисарское тело di
    #38477417
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Где-то в степичего стоит опасаться:
1 если объект захвачен контейнером, при повторном вызове уже освобожденного объекта - можно нарваться на инвалида.
2 если вы запустите объект куда нибудь за облака а потом его отдеспоузите через контейнер - то за облаками будет null.

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

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

не надо вот это вот. об этом сервисе DI пусть позаботиться, а вот этот я сам убью.
хреновая практика это.

остальное by design.
...
Рейтинг: 0 / 0
комисарское тело di
    #38477433
Фотография Где-то в степи
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVostt,
что значит поручить di? как была работа с уничтожением по надобности так и будет, не зависимо откуда объект.
я ведь у ди могу и не поставить using или Dispose, и никакого освобождение ( декларированого) не произойдет, только коллектором через финализатор в будущем,....
...
Рейтинг: 0 / 0
комисарское тело di
    #38477443
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVostt, как ты не понимаешь, оберни ты в единицу работы объекты либо работай непосредственно с объектом, это освобождение уже не контейнером. Те же самые яйца, только через дополнительную абстракцию. Ты точно так же контролируешь жизнь объекта руками через using. А мне не нужны в данном случае дополнительные абстракции в виде единицы работы, у меня и так в руках абстракция сервиса и я знаю, что именно сейчас нужно его шлепнуть. Зачем мне "шлепнуть" дополнительно паковать в UoW? Это называется бездумное программирование ради программирования.
...
Рейтинг: 0 / 0
комисарское тело di
    #38477444
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Где-то в степиhVostt,
что значит поручить di? как была работа с уничтожением по надобности так и будет, не зависимо откуда объект.
я ведь у ди могу и не поставить using или Dispose, и никакого освобождение ( декларированого) не произойдет, только коллектором через финализатор в будущем,....

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

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

или по обстоятельствам?

предлагаешь компонентам вот такие коменты писать:

Код: c#
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
// please kill me
public interface ISomeService: IDisposable
{
...
}

// big brother: don't kill it! I'll do it myself.
public interface IOtherService: IDisposable
{
....
}
...
Рейтинг: 0 / 0
комисарское тело di
    #38477450
Фотография Где-то в степи
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVostt,
по обстоятельствам, я уже ранее высказал свою точку зрение на эти сервисы времени жизни, - фуфло..
...
Рейтинг: 0 / 0
комисарское тело di
    #38477451
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУhVostt, как ты не понимаешь, оберни ты в единицу работы объекты либо работай непосредственно с объектом, это освобождение уже не контейнером. Те же самые яйца, только через дополнительную абстракцию. Ты точно так же контролируешь жизнь объекта руками через using. А мне не нужны в данном случае дополнительные абстракции в виде единицы работы, у меня и так в руках абстракция сервиса и я знаю, что именно сейчас нужно его шлепнуть. Зачем мне "шлепнуть" дополнительно паковать в UoW? Это называется бездумное программирование ради программирования.

это ты не понимаешь в чем смысл наличия Dispose у единицы работы. для удобства.

UOW может быть и таким:

Код: c#
1.
2.
3.
4.
public interface IUOW
{
     void TheEnd();
}



что поменялось? просто стало менее удобно им пользоваться. не получится RAII.

МСУи я знаю, что именно сейчас нужно его шлепнуть

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

МСУЗачем мне "шлепнуть" дополнительно паковать в UoW?

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

представь твоим компонентом IDataContext пользуется другой программист. и ты ему забыл объяснить, что его надо сразу, сабаку такую, убивать на месте. без суда и следствия. и без вопросов!...
...
Рейтинг: 0 / 0
комисарское тело di
    #38477453
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Где-то в степипо обстоятельствам

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

лишь бы без фанатизма
...
Рейтинг: 0 / 0
комисарское тело di
    #38477458
Фотография Где-то в степи
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVostt,
Код: c#
1.
не тебе решать. а контейнеру DI.

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

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

hVosttМСУЗачем мне "шлепнуть" дополнительно паковать в UoW?
я попытаюсь тебе объяснить. потому что может быть ему ещё рано умирать. может конечно и сразу сдохнуть, а может еще пожить и послужить. не тебе решать. а контейнеру DI.
Не рано - это 100%. Я дергаю веб сервис, получаю данные и мне сразу же нужно закрыть сокет, чтобы не держать дорогостоящее соединение. Никаких пожить сервису!

hVosttпредставь твоим компонентом IDataContext пользуется другой программист. и ты ему забыл объяснить, что его надо сразу, сабаку такую, убивать на месте. без суда и следствия. и без вопросов!...
Ради бога. У моего IDataContext есть IDisposable, если у программиста есть голова на плечах, он должен будет высвобождать объект при ненадобности. Классика вроде.
...
Рейтинг: 0 / 0
комисарское тело di
    #38477463
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Где-то в степиэто обыкновенная защита от дурака, которую Вы идеализируете,
Dispose в финализаторе - то же защита от дурака, но право никто же ее не идеализирует..

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

классика, если ты самолично его получил. через new или Container.GiveMeThisItem().

А если тебе его сунули через инъекцию зависимости, такого права уже у тебя нет. есть только допущение, о том, что ты можешь так сделать и тебе ничего за это не будет.
...
Рейтинг: 0 / 0
комисарское тело di
    #38477465
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttМСУСоздавать всегда новый экземпляр - не вопрос, вопрос в том, как и где нужно шлепнуть этот экземпляр.
лишь бы без фанатизма
Я с тобой согласен, есть куча задач с life time, когда с уничтожением по дефолту справляется контейнер. Особенно если идет речь о веб приложениях, так вообще всё просто - жизнь на реквест и море по колено. Но в долгоиграющих песочницах такие шутки уже не прокатят, нужен целенаправленный продуманный ход: попользовался дорогостоящим - освободи, иначе он будет сидеть долго и упорно в "вечном контексте". Вот что я хотел до тебя довести. И только.
...
Рейтинг: 0 / 0
комисарское тело di
    #38477466
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУНикаких пожить сервису!
...
Рейтинг: 0 / 0
комисарское тело di
    #38477468
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttМСУРади бога. У моего IDataContext есть IDisposable, если у программиста есть голова на плечах, он должен будет высвобождать объект при ненадобности. Классика вроде.

классика, если ты самолично его получил. через new или Container.GiveMeThisItem().

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

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

дык я это понимаю. я только против адской смеси противоречивых подходов. если ты один на проекте и все помнишь -- ну славо богу. на морде у IDataContext не написано, что его надо убить максимум через две строчки кода
...
Рейтинг: 0 / 0
комисарское тело di
    #38477470
Фотография Где-то в степи
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVostt,
да я не обсираю, сам много раз забывал освобождать,
автор и не можем помнить досканально каждую строчку кода проекта
вот по этому и считаю время жизни архитектурным излишеством ( если нужно можно решить другим путем), если куча объектов где там упомнишь все, тут или дробить контейнер на мелкие, или наколку на груди делать,
...
Рейтинг: 0 / 0
комисарское тело di
    #38477472
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttМСУЯ с тобой согласен, есть куча задач с life time, когда с уничтожением по дефолту справляется контейнер. Особенно если идет речь о веб приложениях, так вообще всё просто - жизнь на реквест и море по колено. Но в долгоиграющих песочницах такие шутки уже не прокатят, нужен целенаправленный продуманный ход: попользовался дорогостоящим - освободи, иначе он будет сидеть долго и упорно в "вечном контексте". Вот что я хотел до тебя довести. И только.

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

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

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

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

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

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

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

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

http://codearticles.ru/articles/2421
...
Рейтинг: 0 / 0
комисарское тело di
    #38477893
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУ,

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

ты ничего не подумай, но в твоём решении DI-контейнером даже не пахнет.

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

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

hVosttМСУ, а в рецепте у тебя ничего про DI и не говорится... принципам IoC более менее соответствует, конкретное решение — типичный Service Locator.
Там для демонстрируется декларативный сервис локатор только для главного окна (в идеале нафик не нужно, просто я показываю, как оно вяжется в XAML). Для остальных окон используется честный DI контейнер.
...
Рейтинг: 0 / 0
41 сообщений из 41, показаны все 2 страниц
Форумы / ASP.NET [игнор отключен] [закрыт для гостей] / комисарское тело di
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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