Преимущества IoC и DI в веб-приложениях

Question

Я изучаю инъекцию зависимостей и инверсию управления из книги комплектования, насколько я понял из примеров, IoC можно применять во время инициализации приложения.
Когда приложение запускается, он считывает конфигурационный файл весны xml и инициализирует компоненты с их зависимостями. Я понимаю преимущества этого, главным образом, способность тестировать совершенно свободные классы - большое преимущество. Я хотел бы понять, как применять IoC и DI в веб-приложении на основе mvc, я создал простое веб-приложение в SpringMVC (я обычно разрабатываю с использованием Stripes), но я не вижу, как я могу воспользоваться преимуществами IoC и DI в потоке веб-приложения, где пользователь перемещается по сайту, вставляет комментарии, передает формы, загружает файлы для бэкэнд для их чтения и возвращает некоторые результаты, извлекает данные из БД.
Все эти действия, конечно же, выполняются после инициализации приложения (на веб-сервере) и где IoC уже применяется. Итак, я пытаюсь понять, действительно ли стоит его изучать. Любые советы/рекомендации/комментарии/ссылки оцениваются

Answer 1

В приложении MVC у вас будет несколько слоев. У вас есть представления, контроллеры и модели, но в некоторых случаях у вас также будет бизнес-уровень и уровень доступа к данным.

Я рекомендую вам разделить проект, чтобы каждый из этих слоев был скомпилирован в свой собственный .jar-файл (или DLL-файл, если вы работаете в .Net). Затем вам нужно следить за ссылками с одного из файлов jar на другой. Ссылки - плохой знак, потому что они означают, что ваши слои связаны.

Итак, как вы держите свои слои независимыми друг от друга? Вам нужно объявить открытый интерфейс каждого из ваших слоев. Если для слоя требуется другой уровень (зависимость), вы не будете добавлять ссылку на зависимость, вместо этого вам нужно зависеть от его интерфейса.

Уровни взаимодействуют друг с другом, отправляя POCOs. Обычные объекты, содержащие данные, но не содержащие поведения. Эти простые объекты являются просто классами и не тесно связаны с каркасом.

Мы делаем это, потому что это помогает нам сохранить конкретные технологии, инкапсулированные внутри слоя. Например, вы можете использовать спящий режим на вашем уровне доступа к данным, но вы хотите сохранить спящий режим внутри вашего уровня доступа к данным. Ваши контроллеры и бизнес-уровень не должны знать, какую технологию доступа к данным вы используете. Это позволит вам в будущем заменить ваши технологии более современными технологиями, не заменяя все ваше приложение.

Когда вы пишете код и компилируете код, ваши слои ничего не должны знать о других слоях. Единственное, о чем они должны знать, это их интерфейсы. Во время выполнения контейнеры IoC будут создавать экземпляры зависимостей и вставлять их в нужное место.

• пользователя отправляет форму
• Маршрутизатор идентифицирует требуемый контроллер
• Контейнер IoC создает экземпляр контроллера
• Контроллер имеет дело с HTTP материалом, он анализирует данные, введенный пользователь, и создает ПОКО объект, который затем передается бизнес-уровню (BL). Контроллер знает о интерфейсе бизнес-уровня, но не о конкретной реализации.
• Бизнес-уровни передают POCO нескольким службам на уровне доступа к данным (DAL)
• Бизнес-уровни знают о интерфейсе DAL, но не о конкретной реализации или конкретных технологиях, используемых для хранения данных.
• Оба DAL и BL были введены контейнером IoC во время выполнения. Это позволяет слоям избегать ссылок друг на друга.

Инверсия зависимостей помогает вам разделить проблемы, но сама по себе не имеет большого значения, и это может привести к мысли, что это не стоит того. Обучение DI - это первый шаг, но вам также нужно взглянуть на другие 4 СОВЕТЫ и принципы, которые используют DI.

Одним из них является лук Архитектура:

Вы можете узнать больше об этом по адресу:

http://blog.thedigitalgroup.com/chetanv/2015/07/06/understanding-onion-architecture/

Я рекомендовал бы вам прочитать:

• Dependency Injection in .NET
• Patterns, Principles, and Practices of Domain-Driven Design