Должен ли я использовать объекты, переданные конструктору во время инъекции? - PullRequest
1 голос
/ 18 сентября 2010

Я понимаю, что один из (возможно, лучших) способов использования инверсии управления - это ввод зависимых объектов через конструктор (инжекция конструктора).

Однако, если я обращаюсь к этим объектам за пределами объекта, использующего их, я чувствую, что нарушаю какое-то правило - так ли это? Я не думаю, что есть какой-либо способ предотвратить это, но я должен установить правило, что (за пределами поддельных объектов) мы никогда не должны вызывать методы из этих объектов?

[РЕДАКТИРОВАТЬ] Вот упрощенный пример того, что я делаю. У меня есть FileController объект, который в основном используется для каталогизации файлов. Он использует объект FileDal, который обращается к базе данных для вставки / запроса / обновления File и Directory таблиц.

В моей реальной реализации я строю контроллер, приказывая Каслу использовать версию DAL для SQL Server, а в своем модульном тесте я использую SQlite-версию DAL в оперативной памяти. Однако из-за того, как реализован DAL, мне нужно вызывать BeginTransaction и Commit для использования FileController, чтобы соединение не закрывалось, и я позже смогу выполнить поиск и утверждение. Почему я должен это делать, не так уж важно, но это привело меня к мысли, что вызов методов для объекта DAL, который используется другими клиентами (контроллерами), не звучит кошерно. Вот пример:

FileDal fileDal = CastleFactory.CreateFileDal();
fileDal.BeginTransaction();
FileController fileController = new FileController(fileDal);
fileController.CallInterestingMethodThatUsesFileDal();
fileDal.Commit();

1 Ответ

2 голосов
/ 18 сентября 2010

Это действительно зависит от типа объекта - но в целом, я бы ожидал, что все будет в порядке.

Действительно, довольно часто одна и та же зависимость вводится во многие объекты. Например, если у вас есть IAuthenticator и несколько классов, необходимых для использования аутентификации, имеет смысл создать один экземпляр и внедрить его в каждый из зависимых классов, предполагая, что им нужна одинаковая конфигурация.

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

...