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

Question

У меня есть 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);

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

Answer 1

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