Dependency Injection, нагнетание «инъекционный» объект (услуги) в newable (юридического лица)

Question

При написании кода мы должны быть в состоянии определить две большие группы объектов:

• Инъекционные препараты
• Newables

http://www.loosecouplings.com/2011/01/how-to-write-testable-code-overview.html

http://misko.hevery.com/2008/09/30/to-new-or-not-to-new/

• Инъекционные являются такими объектами (услуги), которые предоставляют зависимости в их конструкторах эти зависимость, как правило, решена с помощью контейнера IoC, эти объекты могут задать только для других инъекционных в своих конструкторах

• Newable являются объектами, которые также выставляют зависимости в их конструкторах, но newables может спросить только для других newable объектов (лиц, ценность объектов), другая характеристика newable объектов они не должны содержать ссылку на инъекционный объект

Но при написании кода, мы часто нужно «вводить» серв лед (инъектируется) в Entity (новизна)

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

так, как я решил это:

• Создать интерфейс с методом, отображающим зависимость (услуга будет использоваться в этом методе)

• Создать метод расширения для интерфейса и поместить его в другое пространство имен, возможно, в другой сборке, и просто обернуть вызов исходного метода, разрешающего зависимость с помощью службы локатора

Делая это, мы имеют постоянное разделение между новыми и инъецируемыми объектами с возможностью легко использовать услуги в наших новинках

• Как вы думаете?
• Использование локатора обслуживания в методе расширения считается плохой практикой?
• Как вы можете протестировать вызов метода расширения?

Answer 1

Но при написании кода, мы часто должны «вводить» сервисный (инъекционный) в Entity (newable)

Это не к регистру, если вы найдете необходимость сделайте это, тогда есть какая-то функциональность, которая существует в Entity, которая должна находиться в сервисе.

Предположим, что ваш новичок ShoppingCart, а ваша инъекция - это база данных repository. Вы хотите, чтобы это было возможно:

// somehow cart already got the repository 
cart.save(); 

Ну, вы делаете это неправильно. Вместо этого вам нужно переключить вещи вокруг и сделать:

respository.save(cart); 

Если бы вы могли представить ситуацию, когда вы чувствуете потребность сделать это, мы могли бы обсудить специфику этой ситуации.