ASP.Net MVC 6: Инверсия рекурсивных зависимостей

Question

По-прежнему исследуется новый ASP.NET MVC5, теперь со встроенным DI!

Проблем нет до сих пор, я могу просто вводить свои обработчики (я не люблю срочную службу, так как это определяет для меня от платформы интерфейса):

// This method gets called by the runtime. Use this method to add services to the container. 
    public void ConfigureServices(IServiceCollection services) 
    { 
     services.AddApplicationInsightsTelemetry(Configuration); 

     services.Configure<Model.Meta.AppSettings>(Configuration.GetSection("AppSettings")); 

     services.AddSingleton(typeof(Logic.UserEndPointConfigurationHandler)); 
     services.AddSingleton(typeof(Logic.NetworkHandler)); 

     services.AddMvc(); 
    } 

Работает отлично, также сильно типизированный Configuration-Object «AppSettings» работает отлично.

Также также работает инжектор в контроллерах. Но теперь мое сворачивание: Я отделено мой DATAACCESS из обработчиков, и очевидно, что я хотел бы, чтобы ввести их, а также:

public class UserEndPointConfigurationHandler 
{ 
    private readonly DataAccess.UserEndPointAccess _access; 

    public UserEndPointConfigurationHandler(DataAccess.UserEndPointAccess access) 
    { 
     _access = access; 
    } 

Но бац, UserEndPointAccess не может быть решен. Поэтому кажется, что даже я напрямую обращаюсь к DI классу с параметрическим конструктором, мне нужно его зарегистрировать. Для этого случая, конечно, я должен Интерфейс и зарегистрировать их, но что это значит для внутренних вспомогательных классов, которые я также вводил?

Согласно документам: http://docs.asp.net/en/latest/fundamentals/dependency-injection.html#recommendations, а также примеры, которые я нашел, все люди в мире, похоже, только взаимодействуют между контроллерами и некоторыми репозиториями. Нет бизнес-уровня и нет классов на разных уровнях абстракции в сборках.

Является ли подход Microsoft DI чем-то совершенно иным, чем хорошим словом «Единство», где я могу действительно разделиться как мелкий зернистый, как хотелось бы?

Заранее спасибо.

Matthias

Редактировать @Nightowl: Я добавить свой ответ здесь, так как это немного дольше. Прежде всего, Unity автоматически создает экземпляры, если я запрашиваю conecrete Type. Это позволяет мне вводить типы I и типы, такие как классы-помощники и т. Д. Мне не нужно. Эта комбинация позволяет мне использовать DI везде.

Также в вашем примере мне нужно знать DataAcces в WebGui, который довольно тесно связан. Ну, я знаю, что есть решения для этого через Reflection, но я надеялся, что Microsoft сделала что-то в этой теме, но, вероятно, это означало бы большую перемену.

Также позволяет Unity хранить экземпляры или инструкции, как их создавать, еще одну огромную функцию, которая отсутствует на данный момент.

Возможно, я просто испорчен, какие утонченные DI-библиотеки делают, вероятно, они также делают многое, но на данный момент Microsoft-Реализация является просто огромным понижением по моей информации.

Answer 1

MVC Core следует за шаблоном composition root, где графы объекта созданы на основе набора инструкций для их создания. Я думаю, вы неверно истолковываете то, что для IServiceCollection. Он не хранит экземпляры, он хранит инструкции о том, как создавать экземпляры. Экземпляры фактически не создаются до тех пор, пока конструктор где-нибудь в графе объектов не запросит его как параметр конструктора.

Итак, вкратце, почему ваш сервис (который вы вызываете UserEndPointAccess) не создается при запросе, потому что вы не настроили IServiceCollection с инструкциями по его созданию.

// This method gets called by the runtime. Use this method to add services to the container. 
public void ConfigureServices(IServiceCollection services) 
{ 
    services.AddApplicationInsightsTelemetry(Configuration); 

    services.Configure<Model.Meta.AppSettings>(Configuration.GetSection("AppSettings")); 

    services.AddSingleton(typeof(Logic.UserEndPointConfigurationHandler)); 
    services.AddSingleton(typeof(Logic.NetworkHandler)); 

    // Need a way to instantiate UserEndPointAccess via DI. 
    services.AddSingleton(typeof(DataAccess.UserEndPointAccess)); 

    services.AddMvc(); 
} 

Так что похоже даже я прямо прошу DI класс с Беспараметрическим-застройщиком, мне нужно зарегистрировать это.

Если вы правильно выполняете DI, каждый класс обслуживания будет иметь только один конструктор. Если у вас более одного, то он известен как bastard injection anti-pattern, что по существу означает, что вы тесно связываете определение своего класса с другими классами, добавляя ссылки на них как внешние значения по умолчанию.

И да, вам необходимо зарегистрировать все требуемые типы (что не является частью регистрации по умолчанию MVC). Это как в Единстве.