Шаблоны проектирования призваны помочь разработчикам программного обеспечения писать лучший код. Когда мы говорим «лучше», это означает, что его легче тестировать, должно быть разделение проблем, и, конечно же, все идет логично (да, конечно, все в программном обеспечении логично)!
Недавно я работал над .NET Core. У меня есть опыт создания приложений RESTFul. .NET Core, похоже, сильно отличается от традиционной разработки ASP.NET MVC. Мне это очень понравилось, и я продолжал кодировать с кофе, пока не застрял в одном пункте: Внедрение зависимостей!
Давайте сначала разберемся со структурой кода.
Мы используем шаблон MVC для управления приложением. Получив любой запрос, Контроллеры проверяют подлинность запроса и затем передают его на Уровень обслуживания. Этот уровень выполняет всю бизнес-логику. Если ему необходимо получить / получить / сохранить / обновить данные из базы данных, этот уровень вызывает уровень БД. Мы также можем называть этот уровень БД уровнем модели. Теперь контроллеры не могут получить прямой доступ к базе данных, аналогично уровень сервисного уровня (бизнес-логика) не может напрямую обращаться к базе данных. Это один из аспектов разделения интересов.
Так в чем проблема
В .NET Core есть класс под названием DBContext, который в основном отвечает за выполнение операций с базой данных. Если вы формируете базу данных, DBContext создается вместе с классами модели. DBContext вводится в IServices во время класса Startup.cs. Теперь, поскольку WebAPI отделен от проекта Model, нам нужно будет связать Model с проектом WebAPI. Это не идеальное решение, поскольку мы хотим добиться разделения проблем.
Итак, давайте инвертируем элемент управления
IoC или инверсия управления - это, по сути, шаблон проектирования, который изменяет поток управления. Допустим, вам нужно приготовить еду на обед. Но вы очень устали или ленивы или как я не умеете готовить !! Поэтому вместо того, чтобы готовить себе обед, вы фактически нанимаете любого повара, чтобы он приготовил обед. Другими словами, вы фактически перевели управление с себя на повара. Довольно круто, не правда ли?
Итак, в структуру нашего проекта, что мы сделали, мы ввели новый проект. Вы можете называть это IoC, Helper, Referer как хотите. Теперь проект IoC может фактически сохранять ссылки уровня модели и уровня обслуживания. Но контроллер должен просто содержать ссылку на проект IoC. Чтобы внедрить любую зависимость, контроллер должен вызвать любой назначенный метод в проекте IoC с его объектом IServices, переданным в качестве аргумента. Теперь IoC может добавить ссылку DBContext на объект IServices. Другими словами, вместо того, чтобы API делать инъекцию, он передает эту конкретную работу проекту IoC, точно так же, как вы заплатили шеф-повару, чтобы он приготовил вам фри, а не жарил себя.
Мы добились разделения задач нашего проекта и внедрения зависимостей .NET Core, просто применив простой и понятный шаблон проектирования, который называется: Инверсия управления!
В проекте IoC мы создаем статический метод под названием RegisterServices. Этот метод принимает объект IServiceCollection, который регистрирует контекст базы данных. Другие службы могут быть зарегистрированы с помощью этого объекта.
Теперь этот метод вызывается в файле Startup.cs, куда мы передаем объект IServiceCollection в качестве аргумента. Поскольку метод является статическим, нам не нужно создавать экземпляр класса Register (проект IoC).
Ниже представлено изображение этого потока. Обратите внимание, что инверсия управления изменяет только поток управления, но поток данных. Это связано с тем, что инверсия шаблона управления стремится разделить структуры классов без изменения потока данных.
Вы можете найти полный код здесь, в моем репозитории GitHub. Не стесняйтесь использовать код. Если вам это нравится, поделитесь и подписывайтесь на меня, чтобы увидеть больше интересных статей. До следующего раза, спасибо за чтение и наслаждайтесь кодированием ...
