powered by simpleCommunicator - 2.0.59     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / ASP.NET [игнор отключен] [закрыт для гостей] / выбор IoC
25 сообщений из 286, страница 10 из 12
выбор 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
25 сообщений из 286, страница 10 из 12
Форумы / ASP.NET [игнор отключен] [закрыт для гостей] / выбор IoC
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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