2016-09-02 7 views
2

Есть ли что-нибудь вроде https://github.com/aspnet/DependencyInjection для старых старых приложений .NET Framework?Библиотека абстракции зависимостей

«Содержит общие абстракции DI, которые используют ядро ​​ASP.NET Core и Entity Framework Core».

Я пишу фреймворк, и я не хочу использовать конкретный контейнер IoC для пользователей.

+0

Вы можете использовать проект «.NET Core», который использует пакеты ** DI **, а затем этот проект предназначен для полной структуры. –

+0

Я собираюсь попробовать. Можете ли вы изменить свой комментарий, чтобы ответить, чтобы я мог принять его, если мне удастся заставить его работать? Я мог бы также использовать некоторую помощь в добавлении такого проекта в существующее решение 4.6.2. – Raine

+2

Предотвращение наличия [общей абстракции DI] (http://blog.ploeh.dk/2014/05/19/conforming-container/) вообще; сделайте свой фреймворк [дружественным к DI] (http://blog.ploeh.dk/2014/05/19/di-friendly-framework/). – Steven

ответ

4

Я пишу рамки, и я не хочу, чтобы заставить конкретный контейнер IoC для пользователей.

Способ сделать это, чтобы создать хорошие точки расширения для пользователей, которые нужно заменить. Наличие общей абстракции DI - плохая идея, потому что это анти-шаблон, называемый Conforming Container. Этот анти-шаблон не является чем-то теоретическим; ASP.NET Core применяет этот анти-шаблон, и результат этого заключается в том, что как поддерживающие Simple Injector, так и владельцы Autofac не смогли создать реализацию адаптера, которая полностью соответствует определенному контракту. Простую историю инжектора можно прочитать here и here и общую дискуссию с Microsoft об этом можно найти here. Вы можете прочитать мое открытое письмо Microsoft в этом потоке here, и вы можете видеть, что поддерживающие Autofac agree с этим утверждением.

В конце концов, Microsoft acknowledged проблема, обещая, что они будут строить хорошие возможности интеграции путем предоставления

адекватных корней композиции на рамки, чтобы сделать интеграцию так гладко, как это может быть.

Так что не допускайте применения анти-шаблона Conforming Container в ваших собственных рамках. Мы уже видим, что Microsoft исправляет проблемы, которые этот анти-шаблон вызвал в следующем незначительном выпуске ASP.NET Core. Вместо этого они предоставляют «хорошие возможности интеграции», как описал Марк Семанн here.

+1

Благодарим вас за ваше время, Стивен. Учитывая состояние явной неопределенности (с точки зрения разработки) ядра asp.net и ядра .net, мне может быть лучше ошибиться на стороне осторожности, а не подражать текущей основной версии asp.net. Я также могу оценить хорошие моменты в статьях, которые вы предоставили. Я до сих пор не уверен в том, как баланс производительности и правильности в данном конкретном случае, но я думаю, что это происходит с территорией :) – Raine

2

Вы можете использовать проект .NET Core, который расходует пакеты DI, а затем этот проект предназначен для полного фреймворка. Вы бы предназначаться один из «полных» целевой каркасных прозвищами (ПМФ), и вы project.json будет выглядеть примерно так:

{  
    "dependencies": { 
    "Microsoft.Extensions.DependencyInjection": "1.0.0" 
    }, 

    "frameworks": { 
    "net46": { } 
    }, 

    "version": "1.0.0-*" 
} 
+0

Пробовал несколько комбинаций и некоторые рефакторинги, но, похоже, нелегко иметь .net-библиотеку ядра в решении .NET 4.6.2. Может быть, я, хотя! – Raine

Смежные вопросы