Какъв модел на инжектиране на зависимост да използвате за 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