Использование IoC-контейнеров, часть 2

Со времен прошлой записи про Inversion of Control, контейнеры таки плотно вошли и пустили корни в нашей повседневной жизни. В новом проекте он используется сплошь и рядом, да и при переписывании частей legacy-кода то и дело норовит внедриться.

Однако, используя контейнеры очень легко забыть о модульности и разделении областей видимости.
Как это обычно происходит: проект только начинается, пишутся первые корневые классы, появляется первый UI. При этом проект еще маленький и кажется, что все его части имеют очень много общего (так и есть на самом деле — мы ведь только начинаем). Мы решили использовать контейнер и при старте приложения все типы в нём сразу зарегистрировали.
Наступило счастье — любой класс мы можем с лёгкостью разрезолвить со всеми его зависимостями. Вроде бы всё хорошо.

Но с ростом появляются издержки. Поскольку всё регистрируется в одном месте — все классы во всех проектах публичные. Поскольку контейнер един — мы не задумываемся об обособленности отдельных проектов (всё равно всё успешно отрезолвится в рантайме).
Как следствие из этого — проблемы с пониманием из-за отсутствия абстрагированных регионов и проекты становится проблематично «выдернуть» из продукта и использовать отдельно (что, во-первых, часто пригождается, а во-вторых, помогает в проектировании).

Как «рецепт успеха» я бы рекомендовал всегда рассматривать проект (или группу проектов с единым назначением) как обособленную единицу, и всегда задумываться о его собственном внешнем интерфейсе (он, обычно, состоит из буквально одного-двух интерфейсов), а не отталкиваться от того, как он будет использован в конкретный момент в конкретном продукте.

Как следствие, каждый такой проект или группа проектов будут, скорее всего, иметь свой собственный контейнер, который упростит разработку конкретной области.

Опубликовать в Facebook
Опубликовать в Google Plus

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *