Прочитав сообщение в блоге Марка Симанна вместе с этот ответ, который ссылается на него, я понимаю недостатки использования шаблона Service Locator по сравнению с внедрением зависимостей через конструктор класса. Я также прочитал этот внедрение зависимостей с помощью Ninject , MVC 3 и с использованием шаблона Service Locator, в котором также обсуждается этот вопрос.
Однако мой вопрос касается именно этого случая:
public class MyController
{
public void GetData()
{
using (var repository = new Repository())
{
// Use the repository which disposes of an Entity Framework
// data context at the end of its life.
}
}
// Lots of other methods.
}
Здесь у меня есть контроллер, который содержит метод, вызывающий репозиторий, который автоматически создает экземпляр внутреннего контекста данных Entity Framework. Этот единственный контекст данных используется, потому что контекст вызывается каждым методом в репозитории, поэтому кажется целесообразным совместно использовать один контекст для всего жизненного цикла объекта репозитория.
Теперь, когда класс контроллера большой, есть большая вероятность, что данный репозиторий не будет использоваться. Поскольку я предполагаю (возможно, ошибочно), что создание экземпляра контроллера домена является дорогостоящей операцией, я бы предпочел этого не делать. Использование шаблона локатора службы позволяет мне отложить создание экземпляра до тех пор, пока контекст действительно не понадобится, но, учитывая веские аргументы против этого в приведенных выше ссылках, я бы предпочел избежать этого.
Поэтому я хотел бы знать, существует ли более эффективный способ использования внедрения зависимостей в приведенном выше случае, который не позволил бы мне без необходимости создавать экземпляр моего репозитория и базового контекста данных.