Вы бы более развернуто что ли написали, где это надо и в чем необходимость именно стандартного решения, а не библиотеки из nuget. Да и если это и нужно(в чем я пока сильно сомневаюсь), то скорее стандартной библиотеке, а никак не языку.
По большому счету, ISettings — это именно что результат разбиения и структурирования. С некоторыми плюшками. И конечно же во многих проектах мой подход совершенно не нужен: как обычно, нужно выбирать инструмент по потребностям.
Основная проблема возникает, когда с одной стороны зависимостей реально много(хоть и конечное количество), а с другой стороны кроме регистрации зависимостей есть ещё дополнительный код инициализации(как в моем примере). Попытка делать всё в единой точке(с чего мы и начинали) с ростом проекта приводит к тому, что контролировать код в этой единой точке становится сильно неудобно + надо как-то контролировать этот пост-регистрационный код. Цель — легкое управление модулями(все их регистрации, настройки, записи в глобальные коллекция типа коллекции фильтров), чтобы можно было очень просто найти модуль, изменить его настройки или вовсе удалить, не разбираясь в куче не относящегося к нему кода. Именно для этого всё и сделано.
Так. Насколько я понимаю, вы думаете, что я написал свой IoC-контейнер. Это не так. С помощью моего подхода можно использовать любой существующий контейнер(тот же Unity или Autofac). А мой пример поясню кодом(под фильтрами я подразумевал фильтры asp.net mvc: FilterAttribute):
public class MvcSettings: ISettings<Container>
{
public void Init(IDependencyResolver resolver)
{
GlobalFilters.Filters.Add(resolver.GetService<CustomAuthorizeFilter>())
}
public virtual void Register(Container container)
{
container.Register(() => new CustomAuthorizeFilter("params"))
}
}
Код максимально упрощен, но он показывает назначение подхода: в одном классе мы и регистрируем фильтр, и получаем его для сохранение в коллекции фильтров.
Во-первых, удаление(RemoveDependency) не пересоздает контейнер и никаким образом не удаляет зависимости из него. Просто на этапе сборки(Build) некий модуль не будет зарегистрирован(и его зависимости).
По поводу функциональности IoC-контейнеров. Приведу пример:
Нам нужно сконфигурировать в asp.net приложении часть asp.net mvc-фреймворка: роутинги, конвертеры, биндеры, фильтры, в том числе фильтры авторизации. Фильтр авторизации нам надо зарегистрировать в IoC-контейнере. А после регистрации всех зависимостей нам надо на этапе настройки mvc добавить сей фильтр в коллекцию фильтров. Подход с созданием settings-модуля позволяет объединить в рамках одного класса как регистрацию фильтра так и его получение с последующим добавлением в коллекцию фильтров(причем в рамках данного класса мы не знаем, когда все зависимости будут зарегистрированы и проверены). Стандартные же функции IoC-контейнера способны оперировать только уровнем регистрации, но не пост-обработки.
Собственная обертка нужна не просто для того, чтобы распихать регистрацию зависимостей по блокам, но и для предоставления полного функционала конфигурирования модулей: и регистрацию зависимостей, и и использование этих зависимостей после регистрации в рамках модуля. Ну и в меньшей степени это нужно для поддержки модулей для любого IoC-контейнера(хоть и во многих популярных контейнерах эта функциональность есть)
Есть небольшая проблема: нет ни одного DI-контейнера, полностью соответствующего поведению контейнера ASP.NET 5. Например, для Unity для регистрации коллекции нужно несколько раз регистрировать сервис. В обсуждении использования Simple Injector с ASP.NET 5 описываются эти проблемы
Я так понимаю, использование встроенного DI-контейнера актуально для общих инфраструктурных вещей. Для сервисов бизнес-логики остаются привычные DI-контейнеры с поддержкой регистрации декораторов, коллекций и т.д.
На mono тестировали. Не вытянули даже половины текущей скорости. А ограничения исходят из области администрирования. Если навскидку, то
— количество одновременных запросов к пулу потоков нужно ставить разумным(к примеру, количество процессоров на машине)
— максимальное количество сетевых соединений в windows нужно увеличивать, иначе всё будет плохо
Я думаю, процессу интеграции с mail.ru мы посвятим одну из статей. Вкратце скажу, что у нас всё-таки больше интеграция с TradingDesk(копирование инвентаря) и отдельно стоит синхронизация аудиторий.
Код максимально упрощен, но он показывает назначение подхода: в одном классе мы и регистрируем фильтр, и получаем его для сохранение в коллекции фильтров.
По поводу функциональности IoC-контейнеров. Приведу пример:
Нам нужно сконфигурировать в asp.net приложении часть asp.net mvc-фреймворка: роутинги, конвертеры, биндеры, фильтры, в том числе фильтры авторизации. Фильтр авторизации нам надо зарегистрировать в IoC-контейнере. А после регистрации всех зависимостей нам надо на этапе настройки mvc добавить сей фильтр в коллекцию фильтров. Подход с созданием settings-модуля позволяет объединить в рамках одного класса как регистрацию фильтра так и его получение с последующим добавлением в коллекцию фильтров(причем в рамках данного класса мы не знаем, когда все зависимости будут зарегистрированы и проверены). Стандартные же функции IoC-контейнера способны оперировать только уровнем регистрации, но не пост-обработки.
— количество одновременных запросов к пулу потоков нужно ставить разумным(к примеру, количество процессоров на машине)
— максимальное количество сетевых соединений в windows нужно увеличивать, иначе всё будет плохо