ASP.NET Core Blazor对比.NET Core MVC与剃须刀 [英] Asp.net core blazor vs .net core mvc with razor

问题描述

使用剃刀和剃刀之间的建筑学区别是什么?

文档建议使用blazor时我必须编写一个Web Api-像传统剃刀一样仍然可以传递模型对象吗?

解决方案

1.什么是传统的多页网站或应用程序?

首先，您需要基本了解传统网站/应用程序的工作方式:对于每次调用/请求，您都将请求发送到服务器，服务器将使用整个页面的 complete HTML进行响应.可以像使用ASP.NET Core MVC或Razor Pages一样动态生成，但只能生成一次.假设您有显示预览的文章列表.当用户点击全部阅读时，传统应用中通常有两种方式:

1. 加载类似/view-article?id = 123的页面，再次发生上述情况(加载整个HTML DOM)
2. 使用JavaScript进行Ajax请求，该请求从/api/get-article?id = 1234之类的API加载所需的内容，并操纵DOM将其显示在所需的位置

没有JavaScript，传统网站就无法互动.通常，您会偏爱第二种方法，因为它速度更快并节省了资源:您不必停留在整个页面上，而是重新加载所需的信息即可(而不是再次渲染整个页面(仅更改了一部分))(文章内容在此示例中)

如果您希望传统页面具有交互性，则需要JavaScript.例如，您可以向某个API添加ajax调用，以在用户单击按钮时显示一些数据，而无需则必须重新加载整个页面.简而言之，大多数工作都在服务器端进行.

2.单页应用程序(SPA)有何区别?

就完整呈现的html页面而言，

SPA仅具有一个 page .如果您像单击文章一样浏览至此，它们将加载一个JavaScript应用程序.它处理那里所有交互的内容.如果用户单击文章，则不会从服务器获取完整的HTML文档！取而代之的是，它仅获取已更改的部分，在本例中为文章.其他所有内容(例如导航栏，页脚，小部件等)将保留-在相反的多页应用中，如果不使用js/ajax，则可以在其中重新加载.

您经常在那里拥有模块化组件和双向数据绑定.这意味着，变量链接到某些HTML元素.变量更改后，元素将自动显示新值.在传统应用中，您必须手动创建事件处理程序才能处理此问题.

对于用户而言，SPA通常比在多页应用程序中浏览页面要快得多.简而言之，大多数工作都在用户浏览器的客户端进行.服务器仅提供静态内容(html，js，css)，并提供API，例如从数据库中获取条目或保存它们.

3.Blazor与这有什么关系?

Blazor应用实际上 是SPA.但是与其他框架的主要区别是Blazor允许您使用C#代码控制客户端和服务器端.为了显示这种好处，让我们看一下其他SPA框架，例如Angular:您可以使用ASP.NET Core构建Angular SPA.在这种情况下，您可以使用TypeScript在Angular中编写客户端.如果需要访问数据，它将对ASP.NET Core服务器C#进行API调用.

这使得很难在这两者之间共享数据:如果您有文章模型，则还需要在服务器上的C#中定义 ，并在客户端上的TypeScript中对其进行定义.使用Blazor，您只需在C#中定义一次，然后在两个站点上重复使用即可.换句话说:您只需要编写C#，而不必关心JavaScript *

这是其背后的基本思想.但是，只有在使用Blazor组件时才如此.如果您还需要一些库尚未移植到Blazor，则仍然需要处理一些JS，但仍然可以从数据绑定中受益.

3.1 Blazor WebAssembly 和 Blazor Server

现在，您已经了解了基本知识，并且需要在两种口味之间做出选择:

Blazor WebAssembly

顾名思义，它基本上使用

该应用程序在服务器上运行，仅使用SignalR Websocket将输出(如单击事件的结果，这会增加另一个HTML元素中的一些计数器)传输到浏览器.这样可以使应用变得更小，更快，但是在服务器端需要更多资源，因为您拥有SignalR连接，并且那里是DOM，这使得在大型设置中更难扩展.

另一方面，这减少了对客户端的要求:它们不需要支持WASM，因此它可以在较旧的浏览器或WASM支持受限的浏览器以及低端设备上运行.但是，由于每个操作都以SignalR调用结束，因此该应用程序将无法离线运行-如果有此要求，请选择Blazor WebAssembly，而不是Blazor Server.

选择什么?

如上所述，这取决于您的需求.例如，如果您需要离线支持，Blazor服务器将不是一个很好的选择.如果您不确定我希望使用 Blazor Server ，并且仅在计划部署非常大的应用程序时真正担心此事.

Imho，Blazor服务器目前更流畅，更灵活.在WebAssembly之前，Blazor Server也变得稳定.当WebAssembly得到进一步发展并获得更广泛的支持时，此建议可能会在将来发生变化.

在这种情况下，您可以稍后迁移！

Blazor WebAssembly和Server都使用Razor组件.这意味着:您可以在两者之间进行更改，而无需重新编写整个代码.从Blazor Server迁移到Blazor WebAssembly时，仅需要浏览器外部的数据调用之类的某些迁移工作.原因是Blazor WASM完全在浏览器中运行，因此您需要一个服务器部分(如ASP.NET Core API项目)来处理它们.

其他信息

我建议 ASP.NET简介官方文档中的Core Blazor .另外一章介绍了有关该平台的许多信息并提供了教程.他们将更深入地讨论诸如事件处理仅举几例，并通过示例进行说明.我试图将其简化为基本概述.

另请参阅: Blazor WebAssembly 3.2.0和 ASP.NET Core 5

What is the archtecture difference between working with razor vs blazor?

Documentation suggest that I have to write an Web Api when using blazor - is it still possible to pass model objects like in traditional razor ?

解决方案

1. What is a traditional multi-page site or application?

First you need to have a basic understanding how traditional websites/apps works: For every call/request, you send a request to the server and the server responds with the complete HTML of the entire page. This can be dynamically generated like with ASP.NET Core MVC or Razor Pages, BUT only once. Let's say you have a list of articles showing a preview. When the user clicks on read all you usually have two ways in traditional apps:

1. Load a page like /view-article?id=123 where the above happens again (loading the entire HTML DOM)
2. Using JavaScript to make an Ajax-Request, which loads the desired content from an API like /api/get-article?id=1234 and manipultes the DOM to display it at the desired position

Without JavaScript, traditional sites are not interactive. Mostly you'll prefer the second approach, cause it's faster and saves ressources: Instead of rendering the entire page again (where only a part of it has changed), you stay on that page and just reload the information you need (the article content in this example)

If you like traditional pages to be interactive, you need JavaScript. For example you can add an ajax call to some API that displays some data when the user clicks a button, without having to reload the entire page. In short we can say, that most of the work happens here on the server side.

2. Where is the difference to single-page applications (SPA)?

SPAs have just a single page, in terms of a full rendered html page. If you navigate there like clicking on article, they load a JavaScript application. It handles everything interactive there. If the user clicks on an article, there is NO complete HTML document fetched from the server! Instead, it only fetches the parts who are changed, in this case the article. Everything else (e.g. navigation bar, footer, widgets etc) will remain - in opposite th multi-page apps, where this may be reloaded if no js/ajax is used.

You often have modulary components there and two-way data binding. This means, a variable is linked to some HTML element. When the variable changes, the element automatically displays the new value. In traditional apps, you'd have to create event handlers manually to handle this.

For the user, a SPA normally is much faster than navigating through pages on multi-page apps. In short we can say, that most of the work happens here on the client side in the browser of the user. The server just serves static stuff (html, js, css) and provides APIs for e.g. fetching entries from the DB or save them.

3. What has Blazor to do with that?

A Blazor app actually is a SPA. But the main difference to other frameworks is, that Blazor lets you control both the client and server side with C# code. To show that benefit, let's look at other SPA frameworks like Angular: You can build an Angular SPA with ASP.NET Core. In this case, you write your client side in Angular with TypeScript. If you need to access data, it will make API calls to the ASP.NET Core server, which is C#.

This make it hard to share data between those two: If you have an article model, it needs to be defined in C# on the server and in TypeScript on the client as well. With Blazor you just define it once in C# and re-use it on both sites. In other words: You just write C# without having to care about JavaScript*

This is the basic idea behind it. But it's only the case when working with Blazor components. If you need some library not being ported to Blazor yet, you still have to handle a bit of JS, but still could benefit of things like the data binding.

3.1 Blazor WebAssembly and Blazor Server

Now you know the basics and you need to decide between two flavours:

Blazor WebAssembly

As the name suggests, it basically uses WebAssembly to run your C# browser directly in the browser. It requires a relatively recent Browser and is not yet supported on all platforms/browsers. Also major engines like Chromium or Safari doesn't support all standardized features yet.

Let's say you have a button with C# code as handler like this:

 <button class="btn btn-primary" @onclick="IncrementCount">Click me</button>

IncrementCount is a C# method. The code got transfered to the client and would be executed in the browser. Imagine it as .NET Core runtime inside the browser, like Silverlight BUT without any external plugins. There is no need to even have ASP.NET Core on the server-side! It can be served from any webserver, as long as you don't need things like DBs from the server side. This makes the app larger (and slower, at least on the first load) but it can be used offline (at least the main logic without API calls). For that reason, it's sometimes called real SPA. Debugging can be a harder here, currently it just support Chromium based browsers.

Blazor Server

The app runs on the server and just transfers the output (like the result of a click event, that increases some counter in another HTML element) to the browser using SignalR Websockets. This makes the app smaller and faster, but requires more ressources on the server-side cause you have a SignalR connection and it's DOM there - making it harder to scale in large setups.

On the other side, this reduces the requirements on the clients: They don't need to support WASM, so it could run on older browsers or browsers with restricted WASM support as well as low-end devices. But since every action ends in a SignalR call, the app won't work offline - if this is a requirement, choose Blazor WebAssembly over Blazor Server.

What to choose?

It depends on your needs, as pointed out above. For example, if you need offline support, Blazor server wouldn't be a good choice. If you're unsure I'd prefer Blazor Server and only really worry about this if you're planning to deploy a very large application.

Imho, Blazor server is currently smoother and more flexible. Blazor Server also got stable before WebAssembly. This recommendation may changes in the future, when WebAssembly has developed further and got more widely supported.

In this case, you can migrate later!

Both Blazor WebAssembly and Server use Razor components. This means: You can change between both, without re-writing your entire code. Some migration work is only required for things like data-calls outside the browser when migrating from Blazor Server to Blazor WebAssembly. The reason is, that Blazor WASM runs entirely in the browser, so you need a server part like an ASP.NET Core API projekt to handle them.

Further information

I recommend the Introduction to ASP.NET Core Blazor in the official documentation. Also the other chapter describing a lot of information about the platform and offers tutorials. They go deepter in detail to topics like data binding or event-handling to just name a few, and illustrating them with examples. I tried to kept it shorter here for a basic overview.

See also: Blazor WebAssembly 3.2.0 and ASP.NET Core 5

这篇关于ASP.NET Core Blazor对比.NET Core MVC与剃须刀的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！