Эшу быдлокодит

Палантир. Часть 7. Dependency injection в master-сервере.
#палантир@eshu_coding

В продолжение предыдущего поста и в завершение серии про сборщик.

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

Кроме того, остальные компоненты, используемые мной также подключены.

Сервис, пишущий в БД через одну очередь - singleton. Кроме него, singleton-ами являются классы "State" (хранится всё взаимодействие со сборшиками slave-ами) и LoadManager, притормаживающий сборщики при риске перегрузки.

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

В виде Transient зарегистрированы всякие служебные штуки, а кроме того, класс Report. В него через DI заведены основные синглтоны. При http запросе на контроллер, выведенный мной для мониторинга, создаётся экземпляр Report.

В конструкторе он сохраняет информацию о состоянии синглтонов в свои поля, после чего сериализуется и отправляется мне,а потом - уничтожается.

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

#кодинг

Telegram

Эшу быдлокодит

Dependency injection (DI).

В процессе написания сборщика я осознал логику современного подхода к проектированию приложений: использования внедрения зависимостей (DI).

Ранее я многократно использовал этот подход для подключения готовых компонентов из ASP.…

www.tg-me.com/us/Эшу быдлокодит/com.eshu_coding/199

332 viewsEshu Marabo, edited  May 10, 2021 at 16:35

Палантир. Часть 7. Dependency injection в master-сервере.
#палантир@eshu_coding

В продолжение предыдущего поста и в завершение серии про сборщик.

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

Кроме того, остальные компоненты, используемые мной также подключены.

Сервис, пишущий в БД через одну очередь - singleton. Кроме него, singleton-ами являются классы "State" (хранится всё взаимодействие со сборшиками slave-ами) и LoadManager, притормаживающий сборщики при риске перегрузки.

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

В виде Transient зарегистрированы всякие служебные штуки, а кроме того, класс Report. В него через DI заведены основные синглтоны. При http запросе на контроллер, выведенный мной для мониторинга, создаётся экземпляр Report.

В конструкторе он сохраняет информацию о состоянии синглтонов в свои поля, после чего сериализуется и отправляется мне,а потом - уничтожается.

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

#кодинг

BY Эшу быдлокодит