Как мне следует упорядочить параметры моего ctor для DI / IOC?

Question

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

Допустим, у меня есть форма, которая создает / обновляет заказ, и я знаю, что ей нужно будет получить список продуктов и клиентов для отображения.Я хочу передать объект Order, который он редактирует, но я также хочу внедрить ProductsService и CustomersService в качестве зависимостей.

Поэтому я хочу, чтобы мой контейнер IoC (какой бы я ни использовал) предоставлял услуги, но предоставление объекта Order для редактирования будет зависеть от вызывающего кода.

Должен ли я объявить конструктор как принимающий объект Order в качестве первого параметра и ProductsService и CustomersService после этого, например:

public OrderForm(Order order, ProductsService prodsSvc, CustomersService custsSvc)

...или зависимости должны быть первыми, а объект Заказа последним, например:

public OrderForm(ProductsService prodsSvc, CustomersService custsSvc, Order order)

Имеет ли это значение?Зависит ли это от того, какой контейнер IoC я использую?Или есть "лучший" способ?

Answer 1

Я не согласен с ответом @aku.

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

Независимо от DI, я считаю полезным прояснить в вашем сознании, по крайней мере, тип состояния, которое содержит каждый объект, например, реальное состояние (порядок), производное состояние (если таковое имеется) и зависимости (сервисы):

http://tech.puredanger.com/2007/09/18/spelunking/

В любом конструкторе или методе я предпочитаю, чтобы реальные данные передавались первыми, а зависимости или внешние данные - последними.Поэтому в вашем примере я бы предпочел первое.

Answer 2

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

Смешивание зависимостей и обычных аргументов усложнит логику вашей программы.

В этом случае было бы лучше объявить свойства зависимости (т. е.удалить зависимости из конструктора) или инициализировать порядок месторождение после строительства IoC Форма заказа и разрешил его зависимости (т.е.удалите обычные параметры из конструктора).

Также вы можете объявить все свои параметры, включая порядок как зависимости.

Answer 3

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

Я полагаю, я мог бы немного утешиться, зная, что объекты OrderForm будут создаваться только с помощью фабричного метода, который гарантирует, что свойство Order установлено после выполнения вызова IoC framework.