温莎城堡女士适配器核心2.0的实现 [英] Castle Windsor Ms Adaptor Core 2.0 Implementation

问题描述

有人可以扩展此处提供的Halil Kalkan（@hikalkan）的说明： https： //github.com/volosoft/castle-windsor-ms-adapter

原始-使用标准Microsoft DI

  public void ConfigureServices（IServiceCollection服务）
 {
 services.AddAutoMapper（）; 
 services.AddMvc（）; 
 services.AddApiVersioning（）; 
 
 services.AddDbContextPool< CIDMSContext>（options => options.UseSqlServer（）））; 
 services.AddScoped< IBuildingRepository，BuildingRepository>（）; 
 services.AddScoped< IComponentRepository，ComponentRepository>（）; 
} 
  

NEW-不起作用。尝试使用Castle.Windsor.MsDependencyInjection

 公共IServiceProvider ConfigureServices（IServiceCollection服务）
 {
服务。 AddAutoMapper（）; 
 services.AddMvc（）; 
 services.AddApiVersioning（）; 
 
 services.AddDbContextPool< CIDMSContext>（options => options.UseSqlServer（）））; 
 //services.AddScoped<IBuildingRepository，BuildingRepository>（）; 
 //services.AddScoped<IComponentRepository，ComponentRepository>（）; 
 
返回WindsorRegistrationHelper.CreateServiceProvider（
个新的WindsorContainer（），服务）； 
} 
  

我遇到了错误：

在尝试激活... Controllers.BuildingController'

我的最终目标是不必对我创建的每个存储库都进行DI。我希望温莎城堡按照惯例进行DI。如果对于.Net Core 2.0还有其他选择，那么我也愿意接受这些选择。

我正在使用Visual Studio 15.4.1 .Net Core 2.0 API项目。

编辑：
CastleWindsor-ASP.NET核心工具

解决方案

我建议不要使用这样的适配器。对于大多数DI容器，事实证明，在新的.NET Core DI抽象之上创建一个良好（完全兼容）的适配器绝非易事。一些容器与Microsoft构建其DI容器的方式根本不兼容，而Castle Windsor就是一个很好的例子。

Castle Windsor维护者已尝试相当长的时间来构建这样的适配器，但是即使在咨询了Microsoft之后，Microsoft 已确认（复制）温莎城堡与MS如何看待容器世界不相容。

城堡不是唯一属于此类的容器。事实证明，诸如Simple Injector，Ninject，Unity和StructureMap之类的内容也与新的.NET Core DI Abstraction不兼容。尽管StructureMap实际上有一个适配器，但是其适配器与抽象不是100％兼容的，当ASP.NET Core框架或第三方库开始依赖于这种不兼容的行为时，这显然会导致问题。甚至对于其他带有适配器的容器，例如Autofac和LightInject，其适配器的问题似乎也不断出现，这证明（IMO）底层模型存在缺陷。

因此，目前没有适用于Castle Windsor的兼容适配器，Castle Windsor的维护人员尚未

但是兼容适配器的缺失是完全不是问题。如windsor论坛此处。从根本上讲，这只是运行几行代码。

更新：
Windsor现在为ASP.NET提供了一个功能（集成包）。核心，可在此处读取的文档。请注意，Windsor维护人员选择不创建适配器实现。该设施通过将内置的DI系统保持在原位而不是替换它来工作。但是，从消费者的角度来看，该设施的运作方式并不那么有趣。

Could someone expand upon the directions Halil Kalkan (@hikalkan) provided here: https://github.com/volosoft/castle-windsor-ms-adapter

ORIGINAL - works using standard Microsoft DI

public void ConfigureServices(IServiceCollection services)
    {
        services.AddAutoMapper();
        services.AddMvc();
        services.AddApiVersioning();

        services.AddDbContextPool<CIDMSContext>(options => options.UseSqlServer(""));
        services.AddScoped<IBuildingRepository, BuildingRepository>();
        services.AddScoped<IComponentRepository, ComponentRepository>();
    }

NEW - does not work. trying to use Castle.Windsor.MsDependencyInjection

public IServiceProvider ConfigureServices(IServiceCollection services)
    {
        services.AddAutoMapper();
        services.AddMvc();
        services.AddApiVersioning();

        services.AddDbContextPool<CIDMSContext>(options => options.UseSqlServer(""));
        //services.AddScoped<IBuildingRepository, BuildingRepository>();
        //services.AddScoped<IComponentRepository, ComponentRepository>();

        return WindsorRegistrationHelper.CreateServiceProvider(
            new WindsorContainer(), services);
    }

I am getting the error:

Unable to resolve service for type '...Repositories.Buildings.IBuildingRepository' while attempting to activate ...Controllers.BuildingController'

My ultimate goal is to not have to DI every single repository that I ever create. I would like Castle Windsor to DI it by convention. If there are other options to doing this for .Net Core 2.0 then I am open to those options as well.

I am using Visual Studio 15.4.1 .Net Core 2.0 API project.

EDIT: CastleWindsor - ASP.NET Core Facility

解决方案

I would advise against using such adapter. Creating a good (fully compatible) adapter on top of the new .NET Core DI abstraction has proven to be a far from trivial task for most DI Containers. Some Containers are simply not compatible with the way Microsoft built their DI Container and Castle Windsor is a good example.

The Castle Windsor maintainers have tried for quite some time to build such an adapter, but even after consulting Microsoft about this, Microsoft acknowledged (copy) Castle Windsor is incompatible to how MS views the world of containers.

Castle isn't the only container that falls into this category. Contains such as Simple Injector, Ninject, Unity and StructureMap have proven to be incompatible with the new .NET Core DI Abstraction as well. Although StructureMap actually has an adapter, their adapter isn't 100% compatible with the abstraction, which might obviously lead to problems when the ASP.NET Core framework, or a third-party library, starts to depend on that incompatible behavior. And even for other containers with an adapter, like Autofac and LightInject, problems with their adapters seem to keep popping up, which proves (IMO) the the underlying model is flawed.

So at this moment in time there is no compatible adapter for Castle Windsor, and the Castle Windsor maintainers haven't decided yet whether they should or even could adapt.

But the absense of a compatible adapter is not a problem at all. Windsor (and other containers) can quite easily be integrated with ASP.NET Core without the use of an adapter, as fir3pho3nixx stated on the Windsor forum here. In its basics, it’s just a few lines of code to get things running.

UPDATE: Windsor has now a Facility (integration package) for ASP.NET Core, the documentation for which can be read here. Note that the Windsor maintainers chose not to create an adapter implementation. The Facility works by keeping the built-in DI system in place instead of replacing it. From a consumer's point of view, however, how the Facility works is not that interesting.

这篇关于温莎城堡女士适配器核心2.0的实现的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！