nopCommerce_4.4功能实现详解-----第9章 先具体实现自定义和扩展.NetCore框架中的管道方法

下面按照自底向上的开发模式来具体实现自定义和扩展.NetCore框架中的管道方法。

1、具体实现自定义和扩展IServiceProvider接口及其方法

修改Iengine、NopEngine：

(1)、在NopEngine类中定义IServiceProvider接口实例，GetServiceProvider()方法自定义和扩展.NetCore框架中IServiceProvider接口实例的内置方法GetService<T>()。

(2)、在NopEngine类中自定义Resolve三个重载方法，通过这三个方法通过调用私有GetServiceProvider()方法来实例化程序中其它的所有接口及其实现类。

“Autofac”第三方依赖注入容器内置的用于对接口及其实现类进行实例化操作方法，被命名为“Resolve”，但是NopEngine类对.NetCore框架中的内置IServiceProvider接口和内置方法GetService<T>()的扩展和具体实现命名为“Resolve”，在命名上就会直接给代码阅读者以错误的暗示：“该方法可能是对“Autofac”第三方依赖注入容器内置方法的扩展”，但是实际上它与“Autofac”第三方依赖注入容器毫无关系，只与.NetCore框架和内置依赖注入容器有关。“nopCommerce4.2、nopCommerce4.3”在NopEngine类的实现中，使用了“Autofac”第三方依赖注入容器，这可能是这些方法被命名为“Resolve”的原因，但是“nopCommerce4.4”的NopEngine类的实现中依然沿用这些命名就毫无道理可言了，因为“nopCommerce4.4”不需第三方依赖注入容器，它通过内置依赖注入容器完成了程序中所有接口及其实现的注入操作。根据NopEngine类Resolve方法扩展和具体实现的类型对象，本人认为把这三个方法命名为“xServiceProvider”、“xService”或“xRequiredService”更为合适。

完成以上定义在NopEngine类实例即可以通过IServiceProvider接口实例，调用Resolve方法来实例化程序中中所有的自定义接口及其实现类，但是到目前为止Resolve方法还不能被使用，因为NopEngine实例中的IServiceProvider接口实例本身没有被实例化/初始化。在“nopCommerce4.3”及其以后的具体实现上IServiceProvider接口实例本身没有被实例化/初始化是通过NopEngine类自定义和扩展的.NetCore框架中内置的管道方法来具体实现的，所以下面将在示例程序中实现内置的管道方法的自定义和扩展。

对以上功能更为具体实现和注释见：21-05-25_Nop4.4(012_自定义和扩展IServiceProvider接口及其方法，默认页被正常启动)。

注意：

在“nopCommerce”程序中不管是通过NopEngine类中的Resolve自定义方法显式实例化的实现类，或通过.NetCore框架+Nop.Web.Framework.Infrastructure.DependencyRegistrar.Register方法+拷贝构造方法，隐式实例化的实现类，“nopCommerce”程序定义，所有的实例对象通通都由NopEngine类调用生成，并由NopEngine实例集体中管理。

2、在NopEngine类中自定义和扩展的.NetCore框架中内置的管道方法

修改Iengine、NopEngine：

(1)、在NopEngine类中定义ConfigureRequestPipeline方法，该方法实现中的第一行语句是：

  //通过.NetCore框架中内置IApplicationBuilder静态实例的ApplicationServices属性，来实例化私有服务提供程序实例。

 _serviceProvider = application.ApplicationServices;

即只要在扩展管道方法中定义了该行语句，NopEngine类实例即可以通过IServiceProvider接口实例，调用Resolve方法来实例化程序中所有的自定义接口及其实现类了。

(2)、修改方法RegisterDependencies， 该方法中添加语句：

 //把类型查找器接口及其实现类注入到“Autofac”第三方依赖注入容器实例。containerBuilder.RegisterInstance(_typeFinder).As<ITypeFinder>().SingleInstance();

注意：

“nopCommerce”程序没有把类型查找器接口及其实现类的注入操作集中定义在Nop.Web.Framework.Infrastructure.DependencyRegistrar.Register方法中，而单独定义在了NopEngine类的RegisterDependencies方法中。本人推测认为“nopCommerce”程序把类型查找器接口及其实现类单独定义在RegisterDependencies方法中，是为了在NopEngine类中现行测试IserviceProvider接口实例及其自定义扩展方法是否能够正常执行和实现其功能。

“nopCommerce”程序把类型查找器接口及其实现类注入操作定义在RegisterDependencies方法中，如果RegisterDependencies方法中没有定义上述语句，则会因为没有把类型查找器接口及其实现类注入到“Autofac”第三方依赖注入容器实例中，直接使用类型查找器接口实例而产生逻辑异常(例如：ConfigureRequestPipeline方法中的var typeFinder = Resolve<ITypeFinder>();语句就会产生上述现象)。

在实际实现中本人把RegisterDependencies方法中的把类型查找器接口及其实现类注入语句操作删除，在Nop.Web.Framework.Infrastructure.DependencyRegistrar.Register方法中添加注入操作语句：

     //文件供应商。

            builder.RegisterType<NopFileProvider>().As<INopFileProvider>().InstancePerLifetimeScope();

            //注册类型查找器实例。

            builder.RegisterType<WebAppTypeFinder>().As<ITypeFinder> ().InstancePerLifetimeScope();

完成上面所有操作，在程序执行后，能够实例化类型查找器实例，并正常启动默认页面。

0022、IRouteProvider、RouteProvider

(3)、RouteProvider类根据.NetCore框架提供MVC路由模式、规则和标准，自定义和扩展了启动项中页面默认路由的模式、规则和标准，并对每个页面与之相应的Controller方法之间定义路由映射。

IRouteProvider接口和RouteProvider类被分割定义在不同项目中，RouteProvider类方法中所自定义的默认路由的模式、规则、标准和路由映射与页面有着直接关系，把RouteProvider类定义在启动项中有一定的情理。但“nopCommerce”程序已经把页面之外的具体实现按照功能，迁移定义在启动项以外的项目中，在启动项中只保留页面实现，本人把Controller迁移定义在Controller项目中也是基于这个因素。经过验证把IRouteProvider接口和RouteProvider类都定义在Nop.Web.Framework.Mvc.Routing中，程序也是可以被正常执行的，这样不但使程序的实现逻辑更加简单、清晰，也符合“nopCommerce”程序实现的功能逻辑和设计思想。

0023、IRoutePublisher、RoutePublisher

(4)、RoutePublisher类通过IRouteProvider接口,实例化程序中所有的路由提供程序实现类之后，并对提供程序类指定方法中所定义的路由的模式、规则、标准和路由映射等，依次进行实例化操作。

(5)、在Nop.Web.Framework.Infrastructure.DependencyRegistrar.Register方法中定义语句：

//路由路由发布器依赖注入操作。

  builder.RegisterType<RoutePublisher>().As<IRoutePublisher>().SingleInstance();

0024、ApplicationBuilderExtensions

(6)、ApplicationBuilderExtensions类的定义方式是根据.NetCore框架中间件的规范和标准进行定义的，由于该类是对内置管道中间件方法的自定义和扩展，即该类就是一个自定义管道中间件。

该类所实现的功能是：对.NetCore框架中内置MVC模板终结点路由中间件的自定义和扩展，它通过NopEngine实例的Resolve方法来实例化程序中所有的路由提供程序实现类之后，依次实例化路由提供程序实例指定方法中所定义的路由的模式、规则、标准和路由映射。

(7)、在Nop.Web.Framework.Infrastructure.NopMvcStartup.Configure方法中定义语句：

//必须添加该语句，否则会出现404错误。

application.UseNopEndpoints();

定义该语句的目的是使用“nopCommerce”自定义MVC模板终结点路由中间件，代替由开发环境自动生成的MVC模板终结点路由中间件。

(8)、在Nop.Web.Startup.Configure方法中删除由开发环境自动生成的MVC模板终结点路由中间件方法，定义“nopCommerce”自定义MVC模板终结点路由中间件方法：

app.ConfigureRequestPipeline();

(9)、按F5执行程序，通过自定义MVC模板终结点路由中间件方法，默认页被正常启动。

对以上功能更为具体实现和注释见：21-05-26_Nop4.4(013_通过自定义和扩展.NetCore框架中的管道方法，默认页被正常启动)。

注意：

本人的示例程序为了快速实现“nopCommerce”程序的功能流程，在上面的示例程序中定义了数据层和服务层，在实际实现上，如果代码阅读者为了使自定义管道方法实现逻辑和具体实现更为简单、清晰，可以在删除数据层(项目Nop.Data)、服务层(项目Nop.Services)、ViewModel后，修改相应Controller类实现及其默认页，保留自定义管道方法实现，默认页也是可以被正常启动的。