DependencyInjection. Эталонное внедрение зависимостей

@limeniye · Регистрация: 19.04.2018

Студворк — интернет-сервис помощи студентам

Приветствую, господа!

Есть у меня MVVM приложение.
На уровне VM я хочу инкапсулировать модель и использовать её не зная бед.

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

Решил не спешить и поинтересоваться:
- стоит ли использовать DependencyInjection;
- если да, в каких случаях;
- каким образом.

Добавлено через 5 минут

C#
1
2
3
4
5
6
7
8
9
10
11
12
    public static class ServiceLocator
    {
        public static ServiceProvider ServiceProvider { get; private set; }
 
        public static void ConfigureServices()
        {
            ServiceProvider = new ServiceCollection()
                .AddLogging()
                .AddSingleton<IHelloworldService, HelloworldService>()
                .BuildServiceProvider();
        }
    }

Немного кода, но, полагаю, это неправильно.

@limeniye · 26.04.2022, 15:55 **[ТС]**

Andrey-MSK, эта тема посему и создана в разделе: C# для начинающих. Я не хочу привязываться конкретно к платформе: будь то ASP, или WPF.

И в примере выше, от меня, стандартный DI от Microsoft.

Цель темы: разобраться, в каких случаях я могу использовать Ios, в каких не могу.

Тут что не ответ -- все разные )))

У меня вообще своё мнение: мне кажется, если мы говорим за сервисы, то там обязательно нужно через конструкторы пробрасывать.
В MVVM же паттрне, или лбом схожем, например MVC, на уровне ViewModel лучше использовать DI.

@Andrey-MSK · 26.04.2022, 16:12

limeniye, прочитайте книгу, может поможет определиться

Добавлено через 57 секунд
По названию - Внедрение зависимостей в .NET

@limeniye · 26.04.2022, 16:12 **[ТС]**

Не по теме:

Andrey-MSK, я читал "Приключения Незнайки и его друзей" -- не помогло.

Обновлено: шутка не актуальна

@Элд Хасп · 26.04.2022, 17:10

Сообщение от limeniye

Я не хочу привязываться конкретно к платформе: будь то ASP, или WPF.

Это неверно.
Даже если взять близкие паттерны MVC, MVP, MVVM, то у них разные требования к реализации Controller, Presenter, ViewModel.
И архитектура Решений хоть и получается в чём-то похожей, но всё же различий достаточно много.

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

Универсальность - это хорошо, но без крайностей, ни в ущерб решению конкретной задачи.

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

@limeniye · 26.04.2022, 17:26 **[ТС]**

Не по теме:

Andrey-MSK, книгу на этой неделе не смогу посмотреть, но недели через 2 — пробегусь.

@Andrey-MSK · 26.04.2022, 17:34

limeniye,

Не по теме:

Вот более новая версия, но на английском - Dependency Injection Principles, Practices, and Patterns

@Элд Хасп · 27.04.2022, 09:40

Сообщение от limeniye

Хочу показать 2 примера от одних и тех же разработчиков, но в разных проектах:
-------------------
-------------------
- почему так?
- в чём разница?

Пример с конструктором ShowViewModel(SourceFeed sourceFeed = null) позволяет создать разные экземпляры ShowViewModel, работающие с разными экземплярами SourceFeed.
Инкапсуляция экземпляра SourceFeed определяется объектом вызывающим конструктор ShowViewModel.

Пример с SimpleIoc позволяет создать разные экземпляры OrganizationListPageViewModel, но все они будут работать с одними и теми же экземплярами IStackNavigationService, IVSTSRepository, IUserPreferencesService.
По фактически использованию эти экземпляры скорее всего являются Синглтонами.
Их инкапсуляция определяется видимостью типов (в данном случае интерфейсов) по которым они зарегистрированы.
Скорее всего они публичные и значит все эти экземпляры тоже публичны и доступны во всём приложении, то есть это полная противоположность инкапсуляции.

@limeniye · 27.04.2022, 10:11 **[ТС]**

Andrey-MSK, ну, не совсем так.
Чтобы получить экземпляр — нужно вызвать метод GetService<IStudentsService>(). Это ли не инкапсуляция?

@Элд Хасп · 27.04.2022, 10:20

Сообщение от limeniye

Чтобы получить экземпляр — нужно вызвать метод GetService<IStudentsService>(). Это ли не инкапсуляция?

Если он вызывается для SimpleIoc.Default, то Default - это публичный статический экземпляр.
В большинстве случаев реального применения других экземпляров SimpleIoc и не создаётся.
И по факту это получается публичный Синглтон.
Его метод GetService, тоже может вызвать кто угодно.
Следовательно видимость конкретной перегрузки этого метода GetService<MyType> определяется только видимостью дженерик типа MyType.
Так как интерфейсы практически всегда публичны, то и соответствующая перегрузка тоже публична и доступна всем.
И экземпляр, возвращаемый GetService<IStudentsService>(), может получить кто угодно.
То есть инкапсуляция сведена на нет.

@limeniye · 27.04.2022, 10:41 **[ТС]**

Элд Хасп, а если изменить на internal? И какие есть альтернативы?

@Элд Хасп · 27.04.2022, 11:01

Сообщение от limeniye

И какие есть альтернативы?

Альтернативы чему?
Это же зависит от решаемой задачи.
Невозможно сделать решения подходящего для всех задач.
Исходя из задачи выбирается та или иная реализация.

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

@limeniye · 27.04.2022, 11:06 **[ТС]**

Элд Хасп, в моём понимании, по стандарту обычно, создают локально модель, а потом пробрасывают через конструкторы.
В таком случае модель всегда приватная, от сего, в моём понимании — инкапсулирована от View и всех других типов, не отвечающих за слой VM.

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

@Andrey-MSK · 27.04.2022, 11:42

limeniye, Вот примерно что такое DI, это цитата из книги, которую я вам советовал почитать

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

@Элд Хасп · 27.04.2022, 12:18

Сообщение от limeniye

инкапсулирована от View и всех других типов, не отвечающих за слой VM.

Но метод SimpleIoc.Default.GetService<T>() доступен для всех, то есть это полная противоположность инкапсуляции.
Вы же тем не менее пишите Это ли не инкапсуляция?.
Что здесь вы подразумеваете под инкапсуляцией?

Сообщение от limeniye

обычно, создают локально модель, а потом пробрасывают через конструкторы

В такой реализации за инкапсуляцию отвечает слой создающий экземпляр Модели.
VM никак не может знать сохранена ещё где-лиибо ссылка на эту модель или нет.
То есть, с точки зрения VM, это не инкапсуляция экземпляра модели, а только инкапсуляция переменной (поля) VM хранящей ссылку на экземпляр Модели.
С точки зрения Реализации Приложения, то такую реализацию VM можно использовать и для инкапсуляции экземпляра, но реализовывать эту инкапсуляцию будет уже объект (например, App) создающий VM.

Вариант же с GetService лишает App возможности инкапсулировать экземпляр Модели даже если такое понадобится.

@Элд Хасп · 27.04.2022, 13:31

limeniye, может вы имеете ввиду инкапсуляцию получения VieModel'ю нужного ей экземпляра Модели?
Ну, в таком случае без публичных статических экземпляров Моделей не обойтись.
А будут это просто статические свойства/поля или методы возвращающие всегда одни и те же экземпляры - не столь важно.
Реализовать это можно многими разными способами.

Новые блоги и статьи Все статьи Все блоги /
Саморегулирующийся социальный контракт для сервера cross-section. Hrethgir 14.08.2026 С кодом конечно таких глубоких размышлений пока не было, впрочем я уже привык к алгоритмизации. Суть предмета записи: снова в диалоге с нейросетью (я взял пока себе ник для учётки админа - Rector). . . .	Часы электронные Uhbif79 12.08.2026 Выкладываю программу часов. Программа позволяет: 1. Использовать системное время и дату, 2. Есть возможность вводить время и дату вручную. 3. Реализованы 2 будильника: начало и конец рабочего дня. . . .	Часы с будильником на основе класса QLCDNumber Uhbif79 12.08.2026 Всем добрый день, выкладываю программу часов с будильником на основе класса QLCDNumber. Здесь я пробовал самостоятельно создавал классы, впервые столкнулся с видимостью переменной одного класса из. . .	Установка MinGW GCC 16.2 и CMake 8Observer8 10.08.2026 VK Видео: https:/ / vkvideo. ru/ video-240781534_456239017 YouTube: eY5-5PyI9NM Текстовая версия
Неделя из жизни имитационной модели склада: мои кривые руки растут, откуда надо anaschu 10.08.2026 Неделя из жизни имитационной модели склада: как я почти написал неправильную логику и что с этим делать Работаю сейчас над учебно-рабочим проектом: строю в AnyLogic имитационную модель процессов. . .	Калькулятор для расчета родства russiannick 07.08.2026 1. Задача: Создать калькулятор для расчета родства. Родственных связей существует 8 ступеней, такие как: p - отец P - мать q - муж Q - жена b - брат B - сестра s - сын S - дочь	Мир по моей воле kumehtar 07.08.2026 Когда-то кажется, что всё просто. Ты весь такой светлый. Причиняешь добро. Борешься за справедливость в этом тёмном мире. Потом начинаешь замечать одну неприятную вещь. Почти каждый хороший. . .	Кредитный калькулятор Maks 05.08.2026 Решение задачи по прикладной информатике средствами 1С. Задача: Напишите приложение-калькулятор, которое помогает рассчитывать параметры кредита для аннуитетного и дифференцированного видов. . .

@limeniye 1182 / 624 / 160 Регистрация: 19.04.2018 Сообщений: 2,923
	26.04.2022, 15:55 [ТС]
	Andrey-MSK, эта тема посему и создана в разделе: C# для начинающих. Я не хочу привязываться конкретно к платформе: будь то ASP, или WPF. И в примере выше, от меня, стандартный DI от Microsoft. Цель темы: разобраться, в каких случаях я могу использовать Ios, в каких не могу. Тут что не ответ -- все разные ))) У меня вообще своё мнение: мне кажется, если мы говорим за сервисы, то там обязательно нужно через конструкторы пробрасывать. В MVVM же паттрне, или лбом схожем, например MVC, на уровне ViewModel лучше использовать DI. 0

@Andrey-MSK 3390 / 2276 / 388 Регистрация: 14.08.2018 Сообщений: 7,696 Записей в блоге: 4
	26.04.2022, 16:12
	limeniye, прочитайте книгу, может поможет определиться Добавлено через 57 секунд По названию - Внедрение зависимостей в .NET 0

@limeniye
	26.04.2022, 16:12 [ТС]
	Не по теме: Andrey-MSK, я читал "Приключения Незнайки и его друзей" -- не помогло. Обновлено: шутка не актуальна 0

@limeniye
	26.04.2022, 17:26 [ТС]
	Не по теме: Andrey-MSK, книгу на этой неделе не смогу посмотреть, но недели через 2 — пробегусь. 0

@Andrey-MSK 3390 / 2276 / 388 Регистрация: 14.08.2018 Сообщений: 7,696 Записей в блоге: 4
	26.04.2022, 17:34
	limeniye, Не по теме: Вот более новая версия, но на английском - Dependency Injection Principles, Practices, and Patterns 0

@limeniye 1182 / 624 / 160 Регистрация: 19.04.2018 Сообщений: 2,923
	27.04.2022, 10:11 [ТС]
	Andrey-MSK, ну, не совсем так. Чтобы получить экземпляр — нужно вызвать метод `GetService<IStudentsService>()`. Это ли не инкапсуляция? 0

@limeniye 1182 / 624 / 160 Регистрация: 19.04.2018 Сообщений: 2,923
	27.04.2022, 10:41 [ТС]
	Элд Хасп, а если изменить на internal? И какие есть альтернативы? 0

@limeniye 1182 / 624 / 160 Регистрация: 19.04.2018 Сообщений: 2,923
	27.04.2022, 11:06 [ТС]
	Элд Хасп, в моём понимании, по стандарту обычно, создают локально модель, а потом пробрасывают через конструкторы. В таком случае модель всегда приватная, от сего, в моём понимании — инкапсулирована от View и всех других типов, не отвечающих за слой VM. Следовательно я искал этому альтернативы, но через конструкторы неудобно. 0

@Andrey-MSK 3390 / 2276 / 388 Регистрация: 14.08.2018 Сообщений: 7,696 Записей в блоге: 4
	27.04.2022, 11:42
	limeniye, Вот примерно что такое DI, это цитата из книги, которую я вам советовал почитать Внедрение зависимостей – это прекрасный способ уменьшить сильное связывание между компонентами программного обеспечения. Вместо жесткого кодирования зависимостей, например, указания драйвера базы данных, вы внедряете перечень сервисов, которые могут понадобиться компоненту. Затем сервисы соединяются при помощи стороннего компонента. Эта методика позволяет вам лучшим образом справляться с будущими изменениями и другими возникающими в вашем программном обеспечении сложностями. 0

@Элд Хасп Модератор 16165 / 11285 / 2891 Регистрация: 21.04.2018 Сообщений: 33,174 Записей в блоге: 2
	27.04.2022, 13:31
	limeniye, может вы имеете ввиду инкапсуляцию получения VieModel'ю нужного ей экземпляра Модели? Ну, в таком случае без публичных статических экземпляров Моделей не обойтись. А будут это просто статические свойства/поля или методы возвращающие всегда одни и те же экземпляры - не столь важно. Реализовать это можно многими разными способами. 1