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

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

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

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

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


data-access-layer business-logic asp.net-mvc-2
person JustinMichaels    schedule 19.06.2010    source источник

Ответы (1)


arrow_upward
2
arrow_downward

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

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

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

person ckramer    schedule 19.06.2010
comment
Я считаю, что последнее, что я, возможно, сделал свои классы уровня бизнес-логики слишком детализированными. Я собираюсь заняться рефакторингом моих классов уровня бизнес-логики, чтобы инкапсулировать некоторые из связанных функций Business Entities. Проблема в том, что моя модель предметной области велика вместе с множеством несвязанных объектов. Мне все еще любопытно, есть ли какие-нибудь хорошие статьи с некоторыми рекомендациями о том, как создать контейнер, который будет использоваться на разных уровнях вашего приложения? - person JustinMichaels; 19.06.2010
comment
После вашего совета по рефакторингу моих классов уровня бизнес-логики в сгруппированные функции. Я упростил свои зависимости и реализовал конструктор для каждого из моих контроллеров и классов BLL, зависимости которых были введены Unity. Я очень ценю помощь и руководство. - person JustinMichaels; 19.06.2010
comment
Я рад, что смог помочь, особенно если это помогло вам найти более простое решение. - person ckramer; 19.06.2010