十五、从此何去何从
这本书就要结束了,我想给大家留下一些自从 Blazor 预览版以来,我们在制作中运行 Blazor 时遇到的一些事情。我们还将讨论从这里到哪里去。
在本章中,我们将涵盖以下主题:
- 在生产中运行 Blazor 的经验
- 后续步骤
技术要求
在这一章中,我们没有使用我们在整本书中所写的代码。
在生产中运行 Blazor 的经验
自从 Blazor 进入预览版以来,我们就一直在生产中运行 Blazor Server。在大多数情况下,一切都没有问题。偶尔,我们会遇到一些问题,我将在本节中与您分享这些知识。
我们将查看以下内容:
- 解决记忆问题
- 解决并发问题
- 解决错误
- 旧浏览器
这些是我们遇到的一些事情,我们已经用一种对我们有用的方式解决了它们。
解决记忆问题
我们最新的升级确实增加了很多用户,随之而来的是服务器上更大的负载。服务器很好地管理内存,但是在这个版本中,后端系统有点慢,所以用户最终按下 F5 来重新加载页面。接下来发生的是电路断开,一个新的电路产生了。旧电路等待用户可能再次连接到服务器 3 分钟(默认情况下)。
用户现在有了一个新的电路,并且永远不会再连接到旧的电路,但是在 3 分钟内,用户的状态仍然会占用内存。对于大多数应用,这可能不是问题,但是我们正在将大量数据加载到内存中;数据、渲染树和所有周围的东西都将保存在内存中。
那么,我们能从中学到什么呢?Blazor 是一个单页应用。重新加载页面就像重新启动一个应用,这意味着我们应该始终确保添加从页面内部更新数据的可能性(如果这对应用有意义的话)。我们还可以确保在数据发生变化时进行更新,就像我们在第 11 章管理州中所做的那样。
在我们的例子中,我们最终向服务器添加了更多内存,然后确保用户界面中有重新加载按钮,可以在不重新加载整个页面的情况下刷新数据。最终目标是添加实时更新,当数据发生变化时,实时更新会持续更新用户界面。
如果向服务器添加更多内存不是一个选项,我们可以尝试将垃圾收集从服务器更改为桌面。那个.NET 垃圾收集有两种模式:
- 工作站模式针对在通常没有太多内存的工作站上运行进行了优化。它每秒运行多次垃圾收集。
- 服务器模式针对通常有大量内存的服务器进行了优化,它优先考虑速度,这意味着它只会每 2 秒运行一次垃圾收集器。
通过更改ServerGarbageCollection
节点,可以在项目文件或runtimeconfig.json
文件中设置垃圾收集器的模式:
<PropertyGroup>
<ServerGarbageCollection>true</ServerGarbageCollection>
</PropertyGroup>
不过,增加内存可能是个更好的主意。
我们注意到的另一点是处理数据库上下文的重要性。在本书中,我们使用了IDbContextFactory
来创建数据上下文的实例,并且在我们处理完它之后,使用Using
关键字。
通过使用这个方法,它将只在短时间内可用,然后被处理掉,快速释放内存。
解决并发问题
我们经常遇到问题,数据上下文已经在使用中,无法从两个不同的线程访问数据库。
这是通过使用IDbContextFactory
并在我们使用完它时处理数据上下文来解决的。
在非 Blazor 网站中,同时加载多个组件从来都不是问题(因为 web 一次只做一件事),所以 Blazor 可以同时做多件事的事实是我们在设计架构时需要考虑的。
解决错误
Blazor 通常会给我们一个很容易理解的错误,但在一些罕见的情况下,我们确实会遇到难以理解的问题。我们可以通过在Startup.cs
中添加以下选项来为我们的电路(对于 Blazor 服务器)添加详细的错误:
services.AddServerSideBlazor().AddCircuitOptions(options => { options.DetailedErrors = true; });
通过这样做,我们将获得更详细的错误。然而,我不建议在生产场景中使用详细的错误。也就是说,我们已经为生产中的内部应用打开了设置,因为内部用户已经了解了它并了解了如何处理它。它让我们更容易帮助我们的用户,错误信息只在网页浏览器的开发者工具中可见,而不是面对用户。
旧浏览器
我们的一些客户在旧系统上运行旧浏览器,尽管 Blazor 支持所有主要浏览器,但这种支持并不包括真正的旧浏览器。我们最终帮助这些客户升级到 Edge 或 Chrome,只是因为我们认为他们不应该使用不再接收安全补丁的浏览器浏览网页。
就连我们家里的电视都可以运行 Blazor WebAssembly,所以旧浏览器可能不是什么大问题,但是说到浏览器支持,还是值得思考的。我们需要/想要支持哪些浏览器?
下一步
至此,我们知道了 Blazor Server 和 Blazor WebAssembly 的区别。我们知道如何创建可重用组件、制作 API、管理状态等等。但是我们从这里去哪里;接下来的步骤是什么?
社区
Blazor 社区并不像其他框架那样庞大,但它正在快速发展。许多人以博客或视频的形式与社区分享内容。YouTube 和 PluralSight 有很多教程和课程。Twitch 拥有越来越多的 Blazor 内容,但在庞大的内容目录中并不总是容易找到。
有几个资源值得一提:
- 我的博客:我的博客有很多 Blazor 的内容,还会有更多(http://engstromjimmy.se/)。
- Blazm :我们写的 Blazm 组件库可以在这里找到(http://blazm.net/)。
-
Coding after Work: We have many episodes of our podcast and our stream covering Blazor.
下班后编码播客:http://codingafterwork.com/。
-
Awesome-Blazor :这里可以找到大量 Blazor 相关的链接和资源(https://github.com/AdrienTorris/awesome-blazor)。
-
Jeff Fritz: Jeff Fritz shares Blazor knowledge (among other things) on Twitch. He also maintains a Blazor library that helps Web Forms developers to adopt Blazor.
抽仔 : https://www .抽仔. tv/csharpfritz
github:https://github . com/fritz and friends/blazowebformomponents
组件
大多数第三方组件供应商,如 Progress Telerik、DevExpress、Syncfusion、Radzen、ComponentOne 等,都投资了 Blazor。有的花钱,有的免费。我们还可以使用许多开源组件库。
这个问题经常出现:我是 Blazor 的新手。我应该使用哪个第三方供应商?我的建议是,在投资图书馆(金钱和/或时间)之前,试着弄清楚我们需要什么。
许多供应商可以做我们需要的所有事情,但是在某些情况下,要让它工作起来需要付出更多的努力。我们开始自己开发网格组件,过了一段时间,我们决定让它开源。
布拉兹姆就是这样出生的。我们有一些特殊的需求(不是什么花哨的东西),但它要求我们必须一遍又一遍地编写大量代码,才能使它在第三方供应商组件中工作。
我们从编写我们的组件中学到了很多,这真的很容易做到。我的建议是不要总是编写自己的组件。专注于我们试图解决的实际业务问题要好得多。
对我们来说,构建一个相当高级的网格组件教会了我们很多关于 Blazor 的内部工作。
想想你需要什么,尝试不同的供应商,看看什么最适合你,也许最好自己构建组件,至少在开始时,了解更多关于 Blazor 的信息。
总结
在这一章中,我们看了我们在生产中运行 Blazor 期间遇到的一些事情。我们还讨论了从这里到哪里去。
在整本书中,我们学习了 Blazor 是如何工作的,以及如何创建基本和高级组件。我们通过身份验证和授权实现了安全性。我们创建并使用了一个连接到数据库的应用编程接口。
我们进行了 JavaScript 调用和实时更新。我们调试了我们的应用并测试了我们的代码,最后但同样重要的是,我们着眼于部署到生产中。
我们现在准备好把所有这些知识带到下一个冒险,下一个应用。我希望你读这本书和我写这本书一样开心。成为 Blazor 社区的一员非常有趣,我们每天都在学习新的东西。
感谢您阅读这本书,请保持联系。我很想了解更多关于你建造的东西!
欢迎来到 Blazor 社区!
版权属于:月萌API www.moonapi.com,转载请注明出处