Какой шаблон внедрения зависимостей использовать для MessageProvider?

У меня есть ContactController, где я настроил сообщение в TempData (это для отображения сообщения на экране после успешной отправки), а в макете есть частичный _Message.cshtml, который должен отображать сообщение, если таковое имеется. Сигнатуры методов ниже:

List<Message> GetMessages(IDictionary<string, object> dictionary);
void SetMessage(IDictionary<string, object> dictionary, string body, MessageType type);

Первоначально я думал о внедрении зависимости MessageProvider в конструктор. Но потом мне пришло в голову: что, если мне нужно сделать это в других контроллерах? Кроме того, чтобы использовать его в частичном представлении, мне нужно разрешить реализацию из контейнера, что я считаю приемлемым решением для использования в классе, который расширяет WebViewPage (учитывая, что я не собираюсь его тестировать).

public MyCustomViewPage()
{
  this.MessageProvider = DependencyResolver.Current.GetService<MessageProvider>();
}

public MessageProvider MessageProvider { get; set; }

Но можем ли мы избежать анти-шаблона Service Locator, используя другой шаблон внедрения зависимостей?

Я подумал, что этот MessageProvider имеет хорошую реализацию по умолчанию, и, поскольку нам может понадобиться использовать его в большем количестве контроллеров в будущем, это может быть хорошим кандидатом на шаблон проектирования Ambient Context согласно книге Внедрение зависимостей в .NET, Марк Симанн.

Таким образом, я устранил бы потенциальную проблему, связанную с необходимостью изменения других конструкторов контроллеров в будущем, если бы мне пришлось устанавливать в них сообщения, я бы избавился от необходимости использовать анти-шаблон Service Locator в конструкторе MyCustomViewPage и моем контроллере. еще можно будет проверить.

Затем я бы использовал следующий код в частичном представлении:

var messages = MessageProvider.Current.GetMessages()

И следующий код в моих контроллерах:

MessageProvider.Current.SetMessage("Message sent successfully.", MessageType.Success);

И в моих тестовых приборах (если бы мне действительно нужна была другая реализация):

MessageProvider.SetMessageProvider(otherImplementation);

Как вы думаете, имеет ли смысл такой подход? Какие недостатки я могу упустить?


person Fabio Milheiro    schedule 17.05.2014    source источник


Ответы (1)


Всем, кто может искать тот же ответ в будущем, я решил использовать для этого Ambient Context по причинам, которые я упомянул в вопросе.

person Fabio Milheiro    schedule 18.05.2014