Я знаю, что люди действительно говорят, что DI - это единственная хорошая модель МОК, но я не понимаю этого.Я постараюсь немного продать SL.Я буду использовать новую платформу MVC Core, чтобы показать вам, что я имею в виду.Первые двигатели DI действительно сложны.Что люди действительно имеют в виду, когда говорят «DI», так это используют некоторые фреймворки, такие как Unity, Ninject, Autofac ... которые делают всю тяжелую работу за вас, где SL может быть таким же простым, как создание фабричного класса.Для небольших быстрых проектов это простой способ сделать IOC, не изучая целую структуру для правильного DI, они могут быть не такими сложными для изучения, но все же.Теперь к проблеме, которой может стать DI.Я буду использовать цитату из документов MVC Core.«ASP.NET Core спроектирован с нуля, чтобы поддерживать и использовать внедрение зависимостей».Большинство людей говорят о DI: «99% вашей кодовой базы не должны знать о вашем контейнере IoC».Так зачем им проектировать с нуля, если об этом должен знать только 1% кода, разве старый MVC не поддерживает DI?Ну, это большая проблема DI, это зависит от DI.Чтобы все работало «КАК ЭТО ДОЛЖНО БЫТЬ СДЕЛАНО», требуется много работы.Если вы посмотрите на новое Action Injection, это не зависит от DI, если вы используете атрибут [FromServices].Теперь DI люди скажут НЕТ, вы должны пойти на Фабрики, а не на это, но, как вы можете видеть, даже люди, делающие MVC, сделали это правильно.Проблема DI видна в фильтрах, а также посмотрите, что вам нужно сделать, чтобы получить DI в фильтре
public class SampleActionFilterAttribute : TypeFilterAttribute
{
public SampleActionFilterAttribute():base(typeof(SampleActionFilterImpl))
{
}
private class SampleActionFilterImpl : IActionFilter
{
private readonly ILogger _logger;
public SampleActionFilterImpl(ILoggerFactory loggerFactory)
{
_logger = loggerFactory.CreateLogger<SampleActionFilterAttribute>();
}
public void OnActionExecuting(ActionExecutingContext context)
{
_logger.LogInformation("Business action starting...");
// perform some business logic work
}
public void OnActionExecuted(ActionExecutedContext context)
{
// perform some business logic work
_logger.LogInformation("Business action completed.");
}
}
}
. Если бы вы использовали SL, вы могли бы сделать это с помощью var _logger = Locator.Get () ;.И тогда мы подходим к представлениям.При всей доброй воле относительно DI они должны были использовать SL для представлений.новый синтаксис @inject StatisticsService StatsService такой же, как var StatsService = Locator.Get<StatisticsService>();.Наиболее рекламируемой частью DI является модульное тестирование.Но то, что делают люди, - это просто тестирование там фиктивных сервисов без цели или необходимость подключать туда движок DI для проведения реальных тестов.И я знаю, что вы можете делать что угодно плохо, но люди в конечном итоге делают локатор SL, даже если они не знают, что это такое.Где не так много людей делают DI, даже не читая сначала.Моя самая большая проблема с DI состоит в том, что пользователь класса должен знать о внутренней работе класса в другом, чтобы использовать его.
SL можно использовать хорошим способом и имеет некоторые преимущества, прежде всего его простоту.