将Blazor WASM作为Blazor服务器端运行

Question

问题

在开发方面，Blazor可以很容易地比Blazor服务器端更容易地被接受。目前，Blazor不支持功能齐全的调试体验，而且启动速度非常慢。这大大降低了开发的速度，比使用Blazor服务器端慢得多。虽然老实说，我个人认为调试经验比缓慢的启动更能减缓开发速度。

拟议解决方案

注意:我在其中包含了“提议”这个词，因为我不确定这个解决方案会带来哪些负面影响，所以请尽管评论我下面的答案。

解决方案是简单地创建一个额外的Blazor服务器端项目，然后将Blazor WASM项目引用到Blazor服务器端项目。然后，向Blazor端的Startup和_Host.cshtml添加一些调整，以正确地使用BazorWASM剃须刀文件和www.root文件。关于这个解决方案的一步一步的解释，请看下面我建议的答案。

更简单地说，这个解决方案只是添加和配置Blazor服务器端项目，而不需要对进行任何更改--和--任何重要的代码复制都会添加到Blazor项目中。

Answer 1

注意:在本例中，我使用的是Visual 2019 16.7.2，模板的版本目前位于3.1.8

1. 创建一个Blazor WASM项目。无论是托管的ASP.NET核心还是独立的选项都会运行良好，但它们将有不同的配置，这将在稍后进行讨论。剩下的选项不会有任何效果。在本例中，我将使用ASP.NET Core托管的来解释有关拥有API控制器的内容。之后还会创建Blazor服务器端项目。

1. 现在，您的项目结构应该与下面的第一个屏幕截图类似。 删除Blazor服务器端项目中突出显示的项，如下面的第二个屏幕快照所示。

1. 将Blazor WASM项目引用到Blazor服务器端项目。

- **ASP.NET Core Hosted** - Reference both the `BlazorWasm.Client` & `BlazorWasm.Server` project.
- **Standalone** - Reference the single Blazor WASM project as is.

1. 转到Blazor服务器端项目的Startup类。在ConfigureServices()中，删除WeatherForecastService和BlazorServer.Data命名空间，然后为HttpClient添加一个服务，该服务将由Blazor项目中的剃刀文件使用。 services.AddScoped(sp => new { BaseAddress =新Uri(sp.GetRequiredService().BaseUri) })； 注意到在生产中，我不建议创建HttpClient的实例。使用IHttpClientFactory代替。访问本文使用IHttpClientFactory实现弹性HTTP请求。

For ASP.NET核心WASM项目

在Configure()中，映射控制器的端点。这将使用X.Server/BlazorWasm.Server项目中的控制器。

App.UseEndpoints(端点=> { endpoints.MapControllers()；…})；

1. 转到Blazor服务器端项目的_Host.cshtml文件夹中的/Pages文件夹。将css/site.css的引用更改为css/app.css，因为Blazor项目的主css文件的文件名是不同的。
2. 最后，在App标记的type属性中更改component，并引用Blazor项目中的App剃刀类文件。在本例中，App类可以在BlazorWasm.Client项目中找到：

就这样!当您运行Blazor服务器端项目时，它应该在没有“加载.”的情况下加载文本。

• 没有对Blazor WASM项目进行任何更改，也没有进行任何重要的代码重复。
• 唯一要改变的是引用和launchSettings.json & appsettings.json。
• 至于Startup中用于Blazor端的配置，您只需在Blazor项目中创建扩展方法，并在Blazor端项目中使用它们。

注意：，老实说，我认为这是理想的(？)只用于开发期间的调试，因为WASM剃须刀文件不会充分利用真正的Blazor服务器端的功能，因为它仍然会使用HTTP请求。

​

​

希望在下面得到反馈！:DD

Answer 2

我建议另一种方法。从服务器项目中引用WASM项目还有其他缺点，但就我个人而言，我认为它是一个架构上不优雅的解决方案。

Blazor Server和WASM在一些关键领域有不同之处：

1. 身份验证: Blazor服务器允许您在运行时自定义对特定区域的访问。在WASM中，授权发生在一次过程中，应用程序代码被完整地发送。
2. 数据库就是访问: Blazor服务器允许直接访问EF核心实体(因为代码只在服务器上执行)。在blazor中，实际上不可能直接访问任何数据库。这也是非常不鼓励的，因为您将向客户端发送连接字符串。因此，您需要为数据访问编写一个单独的web。3.设置文件:您可以在服务器端blazor中拥有同样多的设置文件。默认情况下，客户端blazor只加载appsettings.json。需要一种特殊的机制来包含多个.json文件。

因此，对于大多数应用程序(当然是那些需要数据库访问的应用程序)，您将无法在WASM和服务器端之间共享100%的代码基。

下面是你应该做的事情：

1. 对于上面提到的点，(auth，但大部分是db访问)，创建一个数据访问服务依赖项(比如IDataAccessLayer)。一个实现将直接访问数据库(将在服务器端使用)，另一个实现将通过HttpClient (将用于blazor )访问数据库。
2. 现在，把你的整个应用程序放在一个RCL中。叫它"BlazorAppRCL“。这个RCL显然没有Startup.cs和Program.cs。
3. 为服务器和客户端特定的db access实现创建一个项目
4. 现在，您有以下一组项目：

对于服务器端: BlazorServer (只有设置+ Program.cs + Startup.cs)。它指的是IDataAccessLayer的RCL + Server专用实现

对于托管的WASM: BlazorWebAPI :对于数据库访问，它拥有访问数据库BlazorClientDAL的API : IDataAccessLayer BlazorWASM :BlazorWASM项目的特定实现，所有这三个都指向您的BlazorAppRCL。

关键是使用DI/倒置控制模式来解决WASM和Server之间的分歧。这样，您就可以拥有两个实例WASM和Server实例，并且代码差异最小。注意，WASM WebAPI可以简单地使用服务器端IDataAccessLayer的实现。因此，除了API相关的开销之外，不需要进行额外的编码。