htmlunit有js文件不存在_【复杂系统迁移.NETCore平台系列】之静态文件

源宝导读&＃xff1a;微软跨平台技术框架—.NET Core已经日趋成熟&＃xff0c;已经具备了支撑大型系统稳定运行的条件。本文将介绍明源云ERP平台从.NET Framework向.NET Core迁移过程中的实践经验。

    随着ERP的产品线越来越多&＃xff0c;业务关联也日益复杂&＃xff0c;应用间依赖关系也变得错综复杂&＃xff0c;单体架构的弱点日趋明显。19年初&＃xff0c;由于平台底层支持了分应用部署模式&＃xff0c;将ERP从应用子系统层面进行了切割分离&＃xff0c;迈出了从单体架构向微服务架构转型的坚实一步。不久的将来&＃xff0c;ERP会进一步将各业务拆分成众多的微服务&＃xff0c;而微服务势必需要进行容器化部署和运行管理&＃xff0c;这就要求ERP技术底层必须支持跨平台&＃xff0c;所以将现有ERP系统从.NET Framework迁移到 .NET Core平台势在必行。

    上一篇我们讲述了Erp在改造.Net Core页面的处理&＃xff0c;这一篇我们将讲述在静态文件改造过程中遇到的问题和解决思路。

    在ERP中,不仅仅要支持后端的扩展需求&＃xff0c;还要支撑前端的扩展&＃xff0c;ERP常见的扩展就是项目扩展标准产品的功能&＃xff0c;其中包含JS和CSS的扩展

sea.js的扩展

    ERP采用sea.js的同步js加载机制,sea.js中是通过sea-config.js的配置来通过模块名映射到正确的js路径&＃xff0c;而ERP中sea-config.js因为屏蔽掉手动配置&＃xff0c;所以采取动态生成机制&＃xff0c;通过如下几步完成前端sea-config.js的加载。

我们需要先了解下sea.js的编码规范,以下是js文件的一个示例&＃xff1a;

//OrganizationAppService.js文件/*** AppService代理类* &＃64;author 本代码由代码生成器自动生成&＃xff0c;请不要手工调整* http://localhost:4602/script/Mysoft.PubPlatform.Organization.AppServices.OrganizationAppService/proxy*/define("Mysoft.PubPlatform.Organization.AppServices.OrganizationAppService", function (require, exports, module) { var utility &＃61; require("utility"); //业务逻辑代码 })

{"Mysoft.PubPlatform.Organization.AppServices.OrganizationAppService": { "type": "product", "product": { "path": "PubPlatform/Organization/AppService/OrganizationAppService.js", "description": "\r\n\r\nAppService代理类\r\n&＃64;author本代码由代码生成器自动生成&＃xff0c;请不要手工调整\r\nhttp:localhost:4602scriptMysoft.PubPlatform.Organization.AppServices.OrganizationAppServiceproxy\r\n\r\n", "mtime": 1581492465639 } }}

    根据ERP的扩展要求,会有如下三个文件&＃xff1a;    

• 平台js文件 _frontend_build\platform-module.json。

• 产品js文件 _frontend_build\product-module.json。

• 二开js文件 _frontend\Customize{app}\dist\sea-config.json(app代表系统简称例如cbxt)。

    接下来就是在代码中生成如下的sea-config.js内容,因为上述json内容是一个结构化的内容&＃xff0c;通过程序反序列化加载如上三个文件到内存中,再转换成如下标准的sea-config.js的标准内容&＃xff1a;

var __lang &＃61; !!window.Mysoft ? window.Mysoft.Map6.UI.page.lang : "";seajs.config({ "vars": { "lang": "zh-cn" }, "alias": { "RptUtility": "Report/Common/RptUtility.js", "Mysoft.Report.Preview.RptDownload": "Report/Preview/RptDownload.js",}, "map": [ [/^.*$/, function (url) { return url &＃43; "?_t&＃61;31634695680000000&lang&＃61;" &＃43; __lang; }] ], "base": "/", "debug": true});

    这样就完成了整个js文件的sea.js的整个代码编写到配置加载的整个环路。最后在在Framework的ERP中是通过配置在webconfig的SeaConfigHandler进行加载的。

多语言js的扩展

    ERP的js支持多语言的扩展&＃xff0c;而多语言都存储在后端&＃xff0c;所以js文件的加载是配置在webconfig中配置的StaticFileHandler来扩展功能&＃xff0c;在加载中读取物理文件内容时候,进行多语言替换之后返回到前端。

css文件扩展需求

    css文件加载为了产品进行二次开发扩展也是通过StaticFileHandler的配置来加载&＃xff0c;首先加载产品的css文件&＃xff0c;然后加载项目的css文件&＃xff0c;将两个文件内容进行合并后返回到前端。

静态文件缓存的需求

    在上述的静态文件加载过程中&＃xff0c;都增加了浏览器静态文件缓存的功能,通过max-age 和etag的http头进行标记&＃xff0c;让浏览器知道要缓存静态文件,从而减少对后端服务器的请求数据。

    上一篇文章中我们提到的TagHelper中&＃xff0c;静态文件也可以通过在生成的url中&＃xff0c;拼接文件的的 SHA256的哈希值来直接使用浏览器自带的缓存功能。

    前面我们讲述了静态文件的扩展需求&＃xff0c;这部分在Core的改造中是需要做兼容的&＃xff0c;整个的业务逻辑是不变的,但是Core中没有HttpHanler的处理机制&＃xff0c;所有的请求都是通过Middleware来进行处理,Core中对应静态文件的处理全部是放在StaticFileMiddleware 中&＃xff0c;通过IApplicationBuilder.UseStaticFiles进行引用。

    在Core中提供的默认静态文件加载主要是如下几个类型&＃xff1a;

• FileExtensionContentTypeProvider:用来确定哪些请求是需要静态文件StaticFileMiddleware 进行处理的。

• PhysicalFileInfo&＃xff1a;继承自IFileInfo,用来读取物理文件内容

• PhysicalFileProvider&＃xff1a;继承自IFileProvider&＃xff0c;用来映射物理路径到FileInfo和监听文件是否修改。

    Core静态文件的处理流程如下&＃xff1a;

1. 首先通过FileExtensionContentTypeProvider确定是否需要处理请求。

2. 通过PhysicalFileProvider的GetFileInfo返回IFileInfo对象(实际类型是PhysicalFileInfo,如果文件不存在返回NotFoundFileInfo)。

3. 通过IFileInfo的Exists判断文件是否存在&＃xff0c;如果存在通过CreateReadStream方法返回文件内容。

4. 第一次返回给客户端的ETag和Last-Modified的值&＃xff0c;会在第二次请求返回给服务端&＃xff0c;如果文件没有更改则这两个值在生成规则一样的情况下不会改变,这时候返回给客户端304。

    在讲述了ERP的静态文件扩展需求和.Net Core中静态文件加载原理之后&＃xff0c;接下来就是在.Net Core提供的静态文件功能基础上进行扩展来接入ERP的扩展需求了&＃xff0c;这里我们采用了两个适配器模式来讲解决这个问题&＃xff0c;首先我们看看整体的类图&＃xff1a;

说明:

• PhysicalFileProviderAdapter 和PhysicalFileProvider 是组合关系&＃xff0c;通过重写GetFileInfo来返回IFileHandler对象,代码如下&＃xff1a;

  public IFileInfo GetFileInfo(string subpath) {    var handlers &＃61; IocManager.ServiceProvider.GetServices();    var handler &＃61; handlers.OrderBy(item &＃61;> item.Order)// 优先处理特殊的,默认的优先级最小        .ToList()        .First(item &＃61;>        {            item.InitFile(_provider, _provider.GetFileInfo(subpath));            return item.CanHandler();        });    return handler;}

• 为了兼容默认静态文件处理行为&＃xff0c;默认的DefaultHandler是可以处理所有的需要处理的请求,所以DefaultHandler的Order最大,SeaConfigJsFileHandler因为需要在JsLangeHandler之前处理所以Order最小。

• BaseHandler 主要处理通用逻辑&＃xff0c;并且可以做一些子类的公用代码封装,例如通过如下代码&＃xff0c;确定那种文件类型是这个类需要处理的,这样在JSLangHandler和CssLangeHandler中就可以少些一些代码。

  // BaseHandlerprotected BaseFileHandler(IHttpContextAccessor accessor){ _accessor &＃61; accessor; ContentTypeProvider &＃61; new FileExtensionContentTypeProvider();} protected virtual string HandlerContentType { get; }public virtual bool CanHandler(){ //通过头和物理路径两种条件来获取ContentType,如果都获取不到则不处理 if (!ContentTypeProvider.TryGetContentType(_accessor.HttpContext.Request.Path, out var contentType) ||!ContentTypeProvider.TryGetContentType(FileInfo.PhysicalPath, out contentType)) return false; if (contentType !&＃61; HandlerContentType) return false; return true;} //CssMergeFileHandler protected override string HandlerContentType &＃61;> "text/css"; public override bool CanHandler(){ //忽略swagger的文件 return base.CanHandler() && FileInfo.Name !&＃61; "swagger-ui.css";} //JsLangFileHandlerprotected override string HandlerContentType &＃61;> "application/Javascript"; public override bool CanHandler(){ //忽略swagger的文件 return base.CanHandler() && FileInfo.Name !&＃61; "sea-config.js" && !(FileInfo.Name &＃61;&＃61; "swagger-ui-standalone-preset.js" || FileInfo.Name &＃61;&＃61; "swagger-ui-bundle.js");}

• JsLangFileHandler,CssMergeFileHandler和SeaConfigJsFileHandler都是处理后的内容写入MemoryStream然后通过CreateReadStream 返回给Core的静态文件处理。

• 在BaseHandler中提供InitFile的模板方法,子类重写InnerInit来实现业务逻辑,AppendHeader用来处理浏览器缓存的逻辑。

    相比于Framework散落的静态文件处理&＃xff0c;.NET Core的静态文件处理职责更加明确&＃xff0c;点更加集中。基于适配器的扩展之后,将职责更加明确&＃xff0c;每个FileHandler只有一个职责&＃xff0c;并且在以后需要类似的静态文件功能时候增加一个FileHandler即可,更加易于扩展。

    由于依赖于.Net Core 中Ioc容器提供的获取实现列表的功能,IEnumerable GetServices(this IServiceProvider provider) 方法&＃xff0c;所以这里简单的采用遍历判断的方法&＃xff0c;如果只有获取单个实现的方法的话,这里可以调整为责任链模式,有兴趣的可以尝试一下。

------ END ------

作者简介

熊同学&＃xff1a; 研发工程师&＃xff0c;目前负责ERP运行平台的设计与开发工作。

也许您还想看

【复杂系统迁移 .NET Core平台系列】之迁移项目工程

【复杂系统迁移 .NET Core平台系列】之界面层

招商城科走进武汉研发中心&＃xff0c;现场编码解锁平台内核技术

如何解决大批量数据保存的性能问题

【2019总结篇】谈谈数字化时代&＃xff0c;ERP如何坐稳数字化底座