Автоматическая регистрация в контейнере по атрибутам — теперь с 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();

[pashagoroshko]

Если отбросить факты того, что уже существует много крутых решений для больших проектов и решение из коробки, то ваша реализация вызывает ряд вопросов:

1. Зачем мне ссылка на Unity в моем проекте?

2. У вас какая то проблема с версиями. Версия библиотеки .net7(в 2025, почему не standard?) использует зависимости для .net9, наверное большая часть проектов сломается

3. Про размазанность по коду уже писали, и это действительно неудобно, гораздо удобнее в одном месте ты регистрируешь и конфигурируешь всё что тебе надо

4. Пробежался по коду, вопросы и по неймингу и по реализации. PerThread ну такое, лучше уж было и оставить Scoped.

Резюмирую: этим никто не будет пользоваться.

[nronnie]

Всё правильно, но, по пункту №2 - "netstandard" уже давно "deprecated" и его следует использовать только если нужна совместимость с совсем уж старыми (до .NET 5) framework-ами. А так, следует либо указывать самый старый поддерживаемый (например net6.0), либо, если имеет смысл, то перечислять несколько, например, если хочется или нужно для разных TFM написать разный код или задать разные свойства MSBuild в *.csproj файле.

[ValeriyPus]

1. лучше уж было и оставить Scoped.

Проект делался еще когда был unityContainer, Scoped тогда не было.

И из всего рефакторинга с тех пор только поддержка IServiceCollection и тесты.

Не нравится - делайте рефакторинг, присылайте мне на ревью.

Я буду использовать как минимум в своих Metadata-driven фреймворках )

уже существует много крутых решений для больших проектов и решение из коробки

Мне нужна регистрация по атрибутам.

Подробнее, имена проектов на Github, nuget пакетов.

И т.д., и т.п.

P.S. да, минутный рефакторинг и NetCore 2.0.

С заменой Unity на Unity.Abstractions (Теперь вы можете не тащить в свой проект Unity :) )

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

[nronnie]

Проект делался еще когда был unityContainer, Scoped тогда не было.

Ну, хорошо, (даже если оставить в стороне ценность вашей задумки в целом), но зачем тут вообще Unity сейчас - вы можете объяснить? "То что мертво умереть не может" (с)? Его почти никто не использовал даже когда он был живой, а сейчас у него даже последнему коммиту в его репозиторий, по-моему, уже больше пяти лет :)