У мене інтерфейс називається IContext. Для цього не важливо, що він робить, крім наступного:
T GetService<T>();Що цей метод робить, це подивитися на поточний контейнер DI програми та спроби вирішити залежність. Дуже стандартно, я думаю.
У моєму додатку ASP.NET MVC мій конструктор виглядає приблизно так.
protected MyControllerBase(IContext ctx)
{
TheContext = ctx;
SomeService = ctx.GetService<ISomeService>();
AnotherService = ctx.GetService<IAnotherService>();
}Тож замість того, щоб додавати кілька параметрів у конструктор для кожної послуги (адже це стане дійсно дратівливим і трудомістким для розробників, що розширюють додаток), я використовую цей метод для отримання послуг.
Тепер він почуває себе неправильно . Однак те, як я зараз виправдовую це в своїй голові, - це я можу знущатися над цим .
Я можу. Не буде важко знущатися над IContextтестуванням контролера. Мені все одно доведеться:
public class MyMockContext : IContext
{
public T GetService<T>()
{
if (typeof(T) == typeof(ISomeService))
{
// return another mock, or concrete etc etc
}
// etc etc
}
}Але, як я вже сказав, це почувається неправильно. Будь-які думки / зловживання вітаються.
public SomeClass(Context c). Цей код цілком зрозумілий, чи не так? Зазначається, that SomeClassзалежить від а Context. Помилка, але чекай, це не так! Він покладається лише на залежність, Xяку отримує від контексту. Це означає, що кожного разу, коли ви вносите зміни, Contextце може зламатися SomeObject, навіть якщо ви лише змінювали Contexts Y. Але так, ви знаєте, що ви тільки Yне змінилися X, так SomeClassце добре. Але писати хороший код - це не те, що ви знаєте, а те, що знає новий працівник, коли він дивиться ваш код вперше.