如果您一直紧跟 .NET 世界的最新发展趋势，那么现在您一定听说过 Blazor。

笔者接触软件行业的时间不长，先后接触三种架构

笔者对网站的认知为前端、后端及数据库，使用者在浏览器页面按下按钮或是表单请求，触发前端事件，将收集起来的条件打包送往后端

下载Visual Studio后首先建立一个Blazor解决方案，里面建立Blazor Server项目，方案位置可以自己选择(注：新版Visual Studio将Blazor Server跟Blazor WebAssembly的新建项目模板拆分了，较为直观)

由于笔者当初是用ASP.NET Core API + Blazor Server，所以会以Blazor Server示范，日后研究完Blazor WebAssembly会再将心得补上。

我遇到的大多数 Windows 窗体应用程序都不存在或单元测试覆盖率极低。而且它们通常也很难维护，项目中各种 Form 类的代码背后有数百甚至数千行代码，但它不必是这样。

问题来了，为什么Blazor会知道WeatherForecastService在这里可以调用？

C# 的 GitHub 页面上记载了一长串诱人的想法，其中一些令人头疼的问题仍在讨论中。

昨天看到`FetchData.razor`的代码太长了，为求方便，我们把`@code`的部分抽取出来另成一个文件。

自己建立的Service都必须在Startup.cs(Blazor Server)或Program.cs(Blazor WebAssemlby)注册，但有些基本Service就不用自己做了。