Автоматическая регистрация в контейнере по атрибутам — теперь с IServiceCollection и тестами

[alex1t]

А что будет если есть два класса, реализующий интерфейс. При обычной регистрации будет использоваться тот, что зарегистрирован последним. Или надо использовать named регистрации. А здесь какой порядок будет?

Такая декларативная регистрация, разбросанная по коду на мой взгляд не очень удобна, поскольку требует времени на поиск и идентификацию. Я предпочитаю иметь один класс/метод, в котором все регистрации контейнеров и производятся из корня композиции (обычно Startup.ConfigureServices)

[ValeriyPus]

При обычной регистрации будет использоваться тот, что зарегистрирован последним. Или надо использовать named регистрации. А здесь какой порядок будет?

Тот класс, который зарегистрирован последним. Специально для Вас вышла версия 1.0.0.4. С поддержкой Keyed регистрации. Надо установить name в атрибуте для реализации.

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

Такая декларативная регистрация, разбросанная по коду на мой взгляд не очень удобна, поскольку требует времени на поиск и идентификацию

Скорее, наоборот. Ctrl+T, Открыл интерфейс/класс и смотри.

Регистрации в контейнерах тоже не удобно - по 700 строк бойлерплейта, тяжело мержить, добавил интерфейс\реализацию - иди пиши еще 50 строк, не пропусти ничего и т.д.

[withkittens]

по 700 строк бойлерплейта,

Так они у вас никуда не делись, только теперь размазаны по всему солюшену.

[ValeriyPus]

нет, читайте внимательнее.

98% регистраций - атрибут НА ИНТЕРФЕЙСЕ.

Т.е. строк точно меньше, чем при в регистрации в контейнере. Менее 1 строки на реализацию интерфейса.

Все не "размазано по солюшену", а берется из метаданных к интерфейсу\классу.

С тем же успехом можно сказать, что из-за модификаторов доступа теперь все размазано по солюшену, без единой таблицы импорта\экспорта :).

Размазано по солюшену - это именованные (Keyed) регистрации, и их получение из контейнера :). Вот где место скопления ошибок, не видимых при компиляции.

[pankraty]

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

[ValeriyPus]

Атрибуты на оба интерфейса

[TypeRegistration(LifetimeManagementType.Default)]

на класс

[DerivedTypeRegistration(LifetimeManagementType.Singletone)]

[Lav78]

Unity? В 2025? Ностальгия — мощная штука)

[avenumDev]

А если реализация от интерфейса разделена слоями? Как быть?)

Все вопрос отпал

[ValeriyPus]

С версии 1.0.0.3 поддерживается регистрация типов, интерфейсы для которых могут быть где угодно. При этом регистрируются типы из сборки, где вызываешь .RegisterByAttributes();