AutoCSer 包含一个高效的 WEB 框架与一个可嵌入的高性能 HTTP 服务器组件,它不兼容 ASP.NET / MVC 不依赖于 IIS,需要引用 AutoCSer\Packet\*\AutoCSer.dll + AutoCSer.WebView.dll

对于 WEB 框架主要考虑的问题可能是如何根据数据与模板生成目标 HTML,由服务端生成 HTML 的被称为后端框架,由客户端(主要是 JavaScript 脚本)生成 HTML 的被称为前端框架。
个人认为,后端框架有以下优点:
. 天然的 SEO 友好性。
. 服务端组件的可维护性与健壮性,本质上是服务器端语言与客户端脚本的区别,比如 C# 与 JavaScript 的对比,即使是 TypeScript 也是有很大差距的。
. 客户端一次性请求的完整性,不存在脚本耦合问题。
. 客户端渲染效率高。
. 客户端环境的适应性,就算客户端禁用脚本也能正常渲染,当然这种例外一般都应该是可忽略的。

前端框架有以下优点(都是我个人很看重的):
. 操作数据驱动 UI,与脚本程序交互简捷、灵活。
. 客户端与服务端分工明确。
. 由于模板是可缓存的,一般来说数据(比如 JSON)相对于 HTML 可以减少带宽消耗,并且少量减少服务端 CPU 开销。

一般来说前端框架相对于后端框架一般就有以下缺点:
. SEO 不友好。
. 客户端组件不容易维护,所谓重构火葬场(AutoCSer 的前端渲染引擎在使用 TypeScript 之前一直处于打补丁的模式就是这个原因)。
. 客户端至少需要请求两次服务器(有些前端引擎甚至要发起一堆的请求),而且不能保证模板与数据的匹配。
. 客户端占用内存大,渲染不如后端框架效率高(特别是第一次加载页面时可能会让用户产生明显的等待感),渲染性能依赖于浏览器的脚本引擎(比如 IE6 这种古老的浏览器会非常卡)。
. 给服务端程序制造麻烦,比如数据的循环引用问题,与数据的筛选与重组的问题。

AutoCSer 的 WEB 视图框架,是前后端一体的自动化处理框架,它包含一个后端模板引擎与一个前端 MV 模板引擎,两个模板引擎采用基本一致的模板规则,它在拥有前端框架的优点的同时解决了前端框架的部分缺陷问题:
. 后端引擎针对搜索引擎输出 HTML 用于解决 SEO 问题,但是对于搜索引擎的识别依赖于已知的 User-Agent 的模糊匹配,可能不能识别新的或者小众的搜索引擎。
. HTML 模版不仅可以作为前端渲染引擎的输入数据,对于后端引擎而言它还是类似 GraphQL 的一种输出数据筛选器,后端引擎不仅可以输出 HTML,而且可以将使用到的数据输出为 JSON(不是单纯的 JSON,存在框架依赖需要 eval),所以不论页面数据关系多复杂,客户端都只需要自动的一次性请求数据(包括所有被模板引用到的数据)。
. 不用担心数据的循环引用问题,告别垃圾数据的筛选与重组问题,而且会在编译期报告模板与数据的匹配问题。
. 支持通过类型标识申明配置 [AutoCSer.WebView.ClientType] 使客户端识别与合并同一个数据对象。
该框架需要在工程项目中配置静态代码生成

1. 在目标项目中添加一个继承自 AutoCSer.WebView.Config 的 WEB 视图项目申明配置的 class,并申明 WEB 视图代码生成配置 [AutoCSer.WebView.Config]

参考示例 AutoCSer\Example\WebView\WebConfig.cs

2. 根据需求添加 WEB 应用项,支持 3 种应用模式:
. WEB 视图页面 是框架的核心应用模式,本质是在前后端分离模式的基础上配合自动化数据 API 的实现,对应于传统的动态 HTML 页面。
. AJAX 调用函数,输出 JSON 数据,用于前端界面交互或者类 WEB API 接口调用。
. HTTP 调用函数,用于解决以上两种应用模式不能覆盖的问题(比如 单纯的重定向、文件上传 等),简单的说就是手动处理 HTTP 响应。

3. 给该工程项目配置静态代码生成并编译项目,然后将生成的 WEB 应用代理层代码源文件 {项目名称}.AutoCSer.cs 添加到项目中,其中包含一个继承自 AutoCSer.Net.HttpDomainServer.ViewServer<sessionType> 的 WebServer 类型。

4. 将上一步生成的 WebServer 添加到本地宿主模式的 HTTP 服务器

参考示例 AutoCSer\Example\WebView\Program.cs

短连接性能测试项目
AutoCSer\TestCase\TcpServerPerformance\AutoCSer.TestCase.WebPerformance
AutoCSer\TestCase\TcpClientPerformance\AutoCSer.TestCase.WebPerformanceClient
由于 ab 测试客户端采用单线程轮询模式,而创建连接代价比较大,无法做有效的短连接压力测试,下面分别贴出自带客户端与 ab 的压力测试结果供参考
1024 并发短连接吞吐性能测试
ab 1000 并发短连接吞吐性能测试
下面是 .NET Core 的压力测试结果,相对于 .NET Framework 4.5 有一定的性能提升
.NET Core 1024 并发短连接吞吐性能测试
.NET Core ab 1000 并发短连接吞吐性能测试
由于 ab 测试请求 URI 地址固定,而且不对返回结果做正确性验证,所以 ab 相比自带客户端在长连接测试中能得到更高的跑分,下面贴出 ab 测试 100 长连接的压力测试结果
ab 100 长连接吞吐性能测试
下面是 .NET Core 的压力测试结果,相对于 .NET Framework 4.5 测试吞吐下降了不少,因为 CPU 利用率不到 75% 左右,可能是系统 IO 线程调度策略不同造成的,原因待查。
ab 100 长连接吞吐性能测试

客户端 pipeline 长连接性能测试项目(HTTP 服务端没有做流水线设计支持,对于需要高吞吐的需求应该使用 TCP 接口服务框架 或者 TCP 函数服务框架
AutoCSer\TestCase\TcpServerPerformance\AutoCSer.TestCase.HttpFilePerformance
AutoCSer\TestCase\TcpClientPerformance\AutoCSer.TestCase.HttpFilePerformanceClient