Использование единства для разделения уровня бизнес-логики с уровня доступа к данным

Question

Я реализовал Unity в моем проекте Asp.Net MVC2. В настоящее время я регистрирую свои типы BLL при запуске приложения.

Затем я создал класс под названием UnityControllerFactory, который отвечает за разрешение моих зависимостей внутри моих контроллеров. Я просто использую Property injection, чтобы выполнить это, используя атрибут зависимости.

Следующая мысль заключается в том, чтобы удалить мои зависимости, которые содержатся в моих классах BLL, которые привязаны к конкретной реализации классов слоя DAL. Я также хотел бы иметь возможность сделать это через инъекцию свойств вместо инъекции конструктора, поскольку я ссылаюсь на несколько классов в моих методах класса Bll.

Я надеялся на какое-то руководство по любым решениям, которые решали эту проблему или это полностью переборщило?

Answer 1

Если ваши классы BLL создаются Unity, тогда это не будет проблемой, контейнер будет просто предоставлять зависимости, требуемые классами BLL, когда они созданы. Если это не так, тогда вы столкнетесь с проблемой, просто потому, что, вообще говоря, объект, создающий ваш класс BLL, должен также обеспечивать его зависимости.

Я бы хотел предупредить вас об использовании инъекции на основе свойств. Общее правило в мире Injection Dependency заключается в том, что требуется зависимости должны быть введены через конструктор, а необязательно зависимости должны вводиться через свойства. Если вашему классу требуется другой класс для выполнения его работы, не должно быть никакого способа создать экземпляр класса, не имея также необходимых зависимостей.

Вы упомянули использование инъекции свойств из-за количества зависимостей в ваших классах BLL. Хотя я понимаю это, я думаю, что по-прежнему важно следовать правилу require = constructor. Если вы закончите конструктор с слишком большим количеством зависимостей, то это запах кода, который указывает на проблему где-то в вашем дизайне. Может быть, что класс берет на себя слишком много обязанностей (обычно это происходит, если вы обнаружите, что некоторые методы требуют одной группы зависимостей, а другая группа требует другого набора). Также может быть, что работа, выполняемая с зависимостями, слишком сложна и может быть завернута в другой объект, который мог бы координировать работу зависимых классов.