Каким образом я могу использовать IoC контейнер IServiceProvider в .NET Core Class Library?

Question

[Стас Волянский]

Архитектура приложения является трехуровневой:

• Уровень представления - проект ASP.NET Core;
  
• Уровни бизнес логики и доступа к данным - проекты Class Library Core.
  

Как известно, .NET Core предоставляет свой IoC контейнер - IServiceProvider.
Связь между уровнем представления и бизнес логики обеспечивается в классе Startup проекта ASP.NET Core:

public void ConfigureServices(IServiceCollection services)
        {
            services.AddTransient<IService<Person>, PersonService>();
        }

Хотелось бы узнать, каким образом я могу реализовать данный подход для связи уровней бизнес логики и доступа к данным?

Comments

[Станислав Макаров]

> Уровни бизнес логики и доступа к данным
Что конкретно у вас на этих уровнях? Их далеко не всегда разделяют. Какие сервисы и классы где расположены? Сущности и доступ к БД через ADO.NET или орм-ку - на уровне данных?

[Стас Волянский]

Станислав Макаров: сервисы расположены на уровне бизнес логики, которая выполняет весьма стандартные для этого уровня функции. Что же касается уровня доступа к данным, то на нем используется Entity Framework Core. Следует отметить, что на этом же уровне я использую паттерн проектирования "репозиторий".

Answer 1

[Роман]

А причем тут IoC? Я думал всегда, что IoC наоборот, чтобы разорвать связь между уровнями.

services.AddTransient, PersonService>(); эта строка не связь обеспечивает, она лишь говорит контейнеру, экземпляр какого конкретного класса создавать при запросе его из контейнера.

если вам необходимо, чтобы в конструктор сервиса передавался контекст данных, то добавляем его в IoC контейнер
services.AddTransient<DdContext>(),
а в конструктор сервиса добавляем параметр, например,
public PersonService(DbContext context)
Те, когда вы запросите экземпляр IService, контейнер, скажем так, рекурсивно будет разрешать зависимости, те увидев зависимость сервиса от DbContext, и зная зарегистрированный класс, контейнер сначала создаст DbContext, затем создаст PersonService, передав в него созданный экземпляр DbContext.

Comments

[Стас Волянский]

Конечно, я именно эту цель и преследую. Просто привел пример использования IServiceProvider'а в классе Startup. Проблема в том, что в библиотеке классов нет точки входа и непонятно, как именно использовать этот контейнер в данном случае (между уровнем бизнес логики и доступа к данным). Иными словами, куда следует добавить строку кода, приведенную Вами: "services.AddTransient()"

[Роман]

Стас Волянский: в метод ConfigureServices и добавляем библиотеку в зависимости проекта, если же у вас динамически библиотека подгружается, то тут все посложнее.

[Стас Волянский]

Роман: т. е. в классе Startup следует объявлять зависимости как между слоями представления и бизнес логики, так и между слоями бизнес логики и доступа к данным?

[Роман]

Стас Волянский: Еще раз, это не зависимости между слоями. IoC это как раз избавление от прямых зависимостей, вернее от зависимости конкретной реализации. В ConfigureServices вы задаете какую реализацию IoC контейнеру брать для интерфейса. Скажем слой представления у нас зависит от какого интерфеса(сервиса). Мы делаем реализацию этого сервиса, сервис тоже может зависеть, например, от контекста данных или от какого то другого сервиса(который запросы к WebApi реализует). и IoC контейнеру сообщаем какую реализацию брать. Грубо говоря работает все так, стартует приложение, настраивается методами класса Startup, затем отрабатывает маршрутизация, запрашивается конкретны контроллер, IoC контейнер, смотрит на параметры конструктора и создает экземпляры параметров, а уже какой конкретно объект создавать он смотрит по своей внутренне таблице, которую мы и создаем в ConfigureServices. Те, если мы прописали строчку services.AddTransient < IService, PersonService>(); то если в конструкторе класса (а может и метода даже, только там надо пометить параметр атрибутом [FromServices]), будет параметр IService service, то автоматически создастся экземпляр PersonService и передастся в конструктор. IoC контейнер умный очень, опять же создавая экземпляр PersonService, он и на его параметры будет смотреть и также разрешать зависимости, и тд. Опять же повторюсь, AddTransient(а есть и другие еще методы) лишь сопоставляет интерфейс и конкретную реализацию. Это не обязательно слои приложения, это могут быть логеры, анализаторы, что угодно. Итак итог, мы объявляем какой то интерфейс (а можем и не объявлять), делаем реализацию, в ConfigureServices сопоставляем интерфейс и реализацию, а потом просто пишем
public HomeController(IService service). И все и автоматом все создается. если например у Service тоже есть зависимость в конструкторе, она тоже разрешится.

[Стас Волянский]

Роман: я примерно понимаю логику работы IoC контейнера, но Вы так и не ответили на мой вопрос.
Допустим, на уровне доступа к данным есть интерфейс IRepository, класс PersonRepository, реализующий его.
На уровне бизнес логики (проект Class Library) прописан класс PersonService, работающий с PersonRepository, как с сервисом. (Так же заносится в конструктор, как Ваш пример с контроллером: public PersonService(IRepository repository).
В обычном (не Core) проекте я использовал IoC Ninject, где в классе ServiceModule : NinjectModule я биндил интерфейс и класс Bind().To() по аналогии с services.AddTransient, PersonRepository>();
Непонятна именно реализация этого кода для слоев бизнес логики и доступа к данным, как я и писал выше. Так как в Class Library попросту нет класса Startup, как в приложении ASP.NET Core.

[Роман]

Стас Волянский: Все привязки прописываются в Startup классе в ConfigureServices. Мы добавляем в контейнер и PersonService и PersonRepository. IoC работает рекурсивно. Экземпляры будут по цепочке создаваться, зависимости будут автоматически разрешаться.
вот как должно быть в ConfigureServices
services.AddTransient ()
services.AddTransient

Все, в конструкторе контролера достаточно прописать HomeController(PersonService service), все IoC, создаст сначала PersonRepository, потом создаст PersonService, передав в него экземпляр созданного PersonRepository, а потом и создаст контроллер передав в него PersonService. Вы просто заморочились, на библиотеках, но разрешение зависимостей прописывается в одном месте, в ConfigureServices. Да все в одном месте.

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