重回Blazor
上一节我们建立了asp.net core web应用，可是正当我准备基于mvc架构大干一场的时候，事情再次出现了转折。
第一节文章发布后，qq群的一位网友（后来得知头条号：低调的骆驼1，感谢！）向我推荐了一个名为BootstrapBlazor的UI库。这个完全基于Blazor开发，开源协议为Apache-2.0，也同样放置于在码云，这不就是为了我们这个项目量身定做的吗！
先跟大家普及下什么是Blazor。我们来看下来自微软的官方介绍：
- Blazor 是一个使用 .NET 生成交互式客户端 Web UI 的框架：
- 使用 C# 代替 JavaScript 来创建信息丰富的交互式 UI。
- 共享使用 .NET 编写的服务器端和客户端应用逻辑。
- 将 UI 呈现为 HTML 和 CSS，以支持众多浏览器，其中包括移动浏览器。
- 与新式托管平台（如 Docker）集成。
对我来说，最有吸引力的就是第一条，用C#代替JavaScript。我真的特别讨厌Javascript的那种烂代码，看着就头大。现在好了，会C#，通过Blazor，前后端一条龙，太爽了。
下图这是一个使用jstree的前端js代码，我只截了一小部分图，下面还有很长。
js前端都是这样一坨一坨的东西，整段代码看起来就是乱糟糟一片，毫无逻辑和美感。真的是实在没有办法才会去用这玩意。
当我看到了Blazor后，我就一直想用它。我之前尝试过自己用Blazor实现了树控件，已经实现了。然后富文本编辑器我觉得自己做起来太耗时间了，就通过Nuget搜索富文本编辑器。结果就造成了仅仅把目光局限在基于Nuget寻找Blazor的富文本编辑器，却忽视了Gitee这片森林，没有发现BootstrapBlazor的存在。我单纯的以为Blazor还处于开荒时期，相当不成熟。结果却是啪啪打脸，说白了还是对新技术、新平台不熟，没看过、没经历过就不知道什么是好的。
来看下我比较关心的几个控件：树、富文本编辑器、列表在BootstrapBlazor的呈现效果。
树控件
富文本编辑器
列表
看起来很香。然后我对树控件做了一下简单的测试，跟预期的差不多。但是有个地方感觉不爽想要修改它，另外也考虑万一有的地方不满足要求可以对它进行适当的改造。于是到Gitee上下到代码，但是有几个错误怎么都编译不过。后来加群咨询了作者，原来他已经把代码升级到了VS2022+.net 6，可是我现在还不想升级，有点尴尬。
不过正因BootstrapBlazor打开了思路，Gitee上是否还有其他的Blazor库呢？结果一搜，还真的有：
前两个都是带GVP标的，即码云最具价值库。第一个就是BootstrapBlazor，那第二个呢？打开去官网一看，相比BootstrapBlazor看起来更香一点：
一是授权协议为MIT，比BootstrapBlazor的Apache方式更加宽松；
二是由.net基金会支持，由Ant Design Blazor Team维护，而BootstrapBlazor是个人维护的；
然后再看下它的示例样式：
树控件
表格控件
遗憾的是富文本框未找到。不过还是在Gitee上，找到了由百度UEditor的Blazor版，UEditor是基于BSD协议的。而维护这个Blazor版的作者恰恰也是Ant-design-blazor的作者，这个是基于Apache协议的。
UEditor的效果如下：
界面不如Anti-Design的那一套有现代感，不过由于富文本框相对独立，如果后期有更好的可以随时更换，所以这个问题不大。
另外还有一种可能，就是借鉴UEditor和BootstrapBlazor的实现，自己写一个基于Blazor的富文本框。这也是一种可行的解决方案，因为我大概看了下他们的代码，都是基于原本的JS富文本框，然后调用JS引擎来交互，再用Blazor封装，实现起来应该也不难。
至此，我们Web版的框架算是最终确定下来了。这个框架的选择真可谓是一波三折，兜兜转转的又回到原计划了。幸亏是我一个人来做，这要是带团队实际开发项目，得让组员骂死：）
OK，框架已确定，我们继续征程。
一、客户端VS服务端
由于架构发生了变化，所以我们需要重新创建一个基于Blazor的项目。打开Diary解决方案，添加项目，我们注意到，基于Blazor的有两种类型，一种是WebAssembly，一种是Server。
二者有什么区别呢？需要给大家解释一下：
WebAssembly是新的web标准，浏览器会先把网页需要的程序集全部下载到本地，然后程序就可以直接在本地跑了。换句话说，算力直接放到了本地，而不是服务器，有点类似于分布式计算，尤其是网站用户数量大的时候，可以明显降低服务器负荷。有人说，这有什么值得骄傲的？Javascript不也是客户端执行吗？是的，但是Javascript是解释性语言，而WebAssembly是编译后的代码，所以运行效率更高。而对我来说最重要的是，C#语法更优美，javascript不是万不得已，我实在没有兴趣用它。当然弊端也是有的：一是首次加载要把所有依赖性都下载到本地，会慢一些，不过以后再运行由于浏览器缓存的原因，就不需要重新下载了；二是并不是所有浏览器都支持，如下图绿色是支持的，红色是不支持，主流浏览器都支持，IE不支持这种方式。不过展望未来，网速不是问题，落后的浏览器终将淘汰，未来应该看好吧。
Server方式就没什么新意了，微软官方说使用了 SignalR连接，具体没大研究了。毕竟这种方式没有WebAssembly有吸引力。无论哪种方式，二者之间想转换也比较容易，就不多说了。具体自己的项目适合哪种，自己选择。
我个人还是对WebAssembly更感兴趣，这种可以让web版应用更有想象力，比如游戏，效率应该可以接近于原生了吧，直接通过浏览器就跨平台了，想想都觉得很美好。再比如工控行业的内部网，基本不涉及到流量问题，基于Web开发就可以获得与Winform基本相同的运行效率，而且可以跨平台，这绝对是一个重大的进步。
所以教程我选客户端模式，然后下一步。
二、项目选项
考虑到后续如果blazor这个有问题可能还会切换到不同架构的web方案，比如webform或mvc，所以Diary.Web我暂时还保留，新的工程我们取名为Diary.Web.Blazor.WASM。WASM就是WebAssembly的缩写。
继续下一步。
这个界面有几个选项，大概按我的理解说一下，不一定对：
- 配置https，相比http，https安全性更高，但配置和效率都麻烦一些，非大型网站基本没必要；
- asp.net core 托管，这个选项没大看明白，我的理解是如果勾选，会自动集成一个可以运行asp.net core的环境，用来支持运行；
- 渐进式web应用程序，这个选项也没大明白，我的理解是如果勾选，就可以发布一个自带web服务器的可执行程序，使得这个web应用可以离线使用；
以上如果有理解不对的，希望各位看官指出或者补充，感谢！
对我来说上面都不需要，勾掉https，然后点创建。稍等片刻，当页面出现
说明已经创建成功了。
三、运行效果
然后我们将Diary.Web.Blazor.WASM设为启动项目，按F5，稍等片刻，在浏览器中看到的是这个页面：
说明我们的Blazor项目创建成功了。左边是栏目，右边是内容，已经基本符合我们私人笔记的页面结构了。
四、小试牛刀
我们现在要先做点事情熟悉下它的工作原理，第一个任务就是把左上角的Diary.Web.Blazor.WASM换成 私人笔记 四个字。
在WinForm中我们找到那个控件，然后设置下值就搞定了，在web应用中，要怎么来做呢？
我们首先对项目文件做下基本的了解。打开解决方案视图，把解决方案目录都展开，依次对项目文件做下观察：
所有文件大体分成三类：
静态文件：
css目录下是css样式文件，这个是做显示控制的；
sample-data目录，这个顾名思义，是测试数据；
index.html我们打开发现，确实有个Diary.Web.Blazor.WASM的字样
然后我们把它改成 私人笔记，运行看效果，发现我们期望的位置并没有改变，变的是浏览器标签页的位置。
看来位置不对，继续观察其他文件。
页面文件：3个文件分别对应也左侧3个栏目的指向页面，里面也都没有出现Diary.Web.Blazor.WASM的字样。
共享文件：此类文件需要重点观察。
当我们观察到NavMenu.razor文件的时候，我们再次发现了Diary.Web.Blazor.WASM的字样。NavMenu，翻译过来就是导航菜单，那不就是左边的导航栏吗。
于是我们再次修改，然后运行，成功搞定。
虽然修改成功了，但是原理是什么呢？我们按了一下F5，程序怎么就会去调用到NavMenu.razor这个页面呢？我们继续观察文件，在MainLayout.razor文件中，我们发现了有一句<NavMenu />。MainLayout翻译中文就是主布局。
重点来了，我们推测，这条语句应该就是一切的源头了。
那么又是谁调用的App.razor呢？继续观察，在Program.cs中看到了有App的字样。Program.cs一般就是程序入口。
重点来了，我们推测，这条语句应该就是一切的源头了。
builder.RootComponents.Add<App>("#app");
这里有两个App，一个是<App>，一个是"#app"，分别代表什么呢？
在c#语法中，一般类和函数带<>的，都是模板类或模板函数，所以Add<App>就是一个模板函数，这个函数的内部处理以App为类型，具体里面怎么实现的我们就不研究了，我们只需要确定这个App是不是跟App.razor是对应的。怎么确定呢？
最简单的办法就是把App.razor改成App1.razor，看还能不能编译通过，结果是不行。那再把<App>改成<App1>呢，结果可以编译通过。那也就说明这里的<App>与App.razor是一一对应的，这里就是Web程序的源头了。
App搞清楚了，那么第二个#app是什么呢？如果没有特殊的含义，为什么还要作为参数写成字符型呢？万一改成别的会怎样呢？
我的原则是，与其提问，不如一试。初学者就是要不断尝试。况且改一下又没关系，软件开发这个行当好就好在可以拼命的试错，并不需要多少成本。写到这里我想起来，我大学学的是自动化，偏硬件的。然后我就总喜欢试，结果专业课做实验，烧过一个万用表，一个电机，气得专业老师差点让我赔钱。感谢老师没让我赔钱，不过这也打消了我对硬件的兴趣，最后转软件了：）
回到主题，我们把"#app"改成"#app1"，发现并没有报错，但显示的是这样的页面：
一直停留在Loging... 这是为什么呢？带着疑问我们继续观察文件，当看到index.html文件的时候，发现这里有Loading...字样
这时，你是不是突然恍然大悟了：
<div id="app">Loading...</div>
这个id就是app，那我们把这里改成
<div id="app1">Loading...</div>
是不是就正常了呢？答案如我们所料。
至此，<div id="app1>Loading...</div>里面的内容我们基本上明白是怎么产生的了。那这之外的那些html代码又都是什么意思？
考虑到部分初学者可能从来没接触过web编程，所以我大概对这些html标签讲解下，便于理解，当然如果想学的深入还是建议到下方获取相关的链接进行深入学习。
<!DOCTYPE html> 这是html5标准网页声明，有了这个浏览器就知道，你这一堆代码是符合html5规范的
<html> 告诉浏览器，这是一个html文档。
<head>...</head> 这个是网页头，用来定义一些非网页内容正文相关内容。
<meta charset="utf-8" /> 定义网页的字符集，默认是utf-8
<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no" />这个是用来根据不同屏幕大小来做缩放的
<title>私人笔记</title> 网页标题，浏览器标签上显示的内容
<base href="/" /> 规定页面上所有相对链接的基准链接，/就表示网站根目录
<link rel="stylesheet" href="/css/app.css" /> 引入外部css文件
<body></body> 网页内容正文块
<div>、<h1>这些都是标准的html标签，一般div用做内容块，h1用做标题，当然这些是约定俗成的，自己想怎么定义也都可以。
<script src="
_framework/blazor.webassembly.js"></script> 引入外部的js文件，这个blazor.webassembly.js是一个js库，专门用于blazor webassembly 与 浏览器进行交互。
所以讲到这里，我们通过改一个简单的标题的小任务， 大概就把整个网站的结构和运行逻辑基本搞清楚了。可以看出，Blaozr的网站整体结构是非常简洁的，没有那么多臃肿的文件和代码。
我们接下来就要参考第一阶段的步骤，要做分类树了，限于篇幅原因，今天暂时介绍到这里，下节继续。
----------------------------------------------------
本教程项目源码已作为开源项目加入到Gitee，代码内容会随教程实时更新，大家有兴趣的话可以关注我，以获得最及时的更新。私信：
私人日记 可以获取相关链接；
大家阅读过程中有哪些看不懂或未尽兴的地方，可以在评论区留言，我会先记下来在后续的教程中找机会再说。
教程有帮助的话请大家帮忙关注、转发、扩散，能不能开专栏还需要你们的支持！