Blazor笔记-Project Struct

更新记录

注意：非教程。纯笔记，日常查询用的。需要教程的小伙伴找几本书看看即可哈哈，有Vue基础的话非常快，概念都是通的。非工作需要不建议深入学习Blazor，深入Vue吧，用的多，哈哈。

完整目录地址：https://www.cnblogs.com/cqpanda/p/17596348.html

点击查看

2024年3月7日 发布。
2023年8月1日 迁移笔记到博客。

Project Struct

It will render a component called App. There are five different render modes:

• The first one is the default ServerPrerendered mode, which will render all the content
on the server and deliver it as part of the content when the page gets downloaded for
the first time. Then it will hook up the Blazor SignalR hub and make sure your changes
will be pushed to and from the server; however, the server will make another render and
push those changes over SignalR. Typically, you won’t notice anything, but if you are
using certain events on the server, they may get triggered twice and make unnecessary
database calls, for example.

• The second option is Server, which will send over the whole page and add placeholders
for the components. It then hooks up SignalR and lets the server send over the changes
when it is done (when it has retrieved data from the database, for example)

The third option is Static, which will render the component and then disconnect, which
means that it will not listen to events and won’t update the component any longer. This
can be a good option for static data.

• The fourth option is WebAssembly, which will render a marker for the WebAssembly application but not output anything from the component.

• The fifth option is WebAssemblyPrerendered, which will render the component into static HTML and bootstrap the WebAssembly app into that space.

hosting models

Blazor WebAssembly

UI UPDATES

BENEFITS AND TRADEOFFS

Benefits:

• Applications run on the client—This means that there is much less load on the server, so you can offload much of the work to the client. This could lead to significant cost savings on server infrastructure and improve the scalability of an application.

• Can work in offline scenarios—As the app runs entirely inside the browser, there’s no need for a persistent connection to the server, making applications more tolerant to unstable network connections. It’s also trivial to enable progressive web application (PWA) functionality. In fact, Blazor WebAssembly has this as an option you can select when creating your application.

• Deployed as static files—As Blazor WebAssembly apps are just static files, they can be deployed anywhere static hosting is available. This opens up some options that historically have never been available to .NET developers. Services such as GitHub pages, Netlify, Azure Blob Storage, AWS (Amazon Web Services) S3 buckets, and Azure Static Web Apps are all options for hosting standalone Blazor WebAssembly applications. The cost of deploying static files is relatively less compared to hosting web applications in each of the leading Cloud providers.

• Code sharing—Potentially one of the greatest benefits with Blazor WebAssembly is if you’re using C# on the server. You can now use the same C# objects on your client as you use on the server. The days of keeping TypeScript models in sync with their C# equivalent and vice versa are over.

Tradeoffs:

• Payload—When compared to some JavaScript applications, the initial download size of Blazor apps can be much bigger (although this is improving with every release). A minimal Blazor app can be produced that weighs in at about 1 MB when published; however, other apps could be significantly larger. Every application is different, and there is no standard size for a Blazor app. This is a one-time cost, though, as the run time and many of the framework assemblies are cached on the first load, meaning subsequent loads can be as small as a few KB.

• Load time—A knock-on effect of the payload size can be load time. If the user is on a poor internet connection, the amount of time required to download the initial files will be longer, which will delay the start of the application, leaving the user with a loading message of some kind. This can be offset slightly by using server-side prerendering; however, while this will give the user something more interesting to look at initially, the app still won’t be interactive until all files have been downloaded and initialized. Server-side prerendering for Blazor WebAssembly apps also requires an ASP.NET Core element on the server, which negates any free hosting options.

• Restricted run time—This is arguably not a tradeoff as such, but for existing .NET developers who are used to having relatively free rein over the machine their apps run on, it’s something to be aware of. WebAssembly applications run in the same browser sandbox as JavaScript applications. This means, for example, that you will not be allowed to reach out to the users’ machine and do things such as access the local file system.

• Code security—Just as with JavaScript applications, your code is downloaded and run in the browser. Therefore, the user has access to your applications DLLs. This means you should not include any code that contains intellectual property in a Blazor WebAssembly application. Any valuable code should be kept on the server as part of an API.

Blazor Server

UI UPDATES

BENEFITS AND TRADEOFFS

BENEFITS

• Small payload—As the application is running on the server as opposed to the client, the initial download is significantly smaller. Depending on static assets such as CSS and images, a Blazor Server application can be as small as 100-200 KB.

• Fast load time—With a much smaller payload, the application loads much faster. The server-side prerendering also helps, as the user never sees a loading message.

• Access to the full run time—The application code is executing on the server on top of the full .NET run time. This means you can do things such as access the server’s file system if necessary without hitting any security restrictions.

• Code security—If you have code that is proprietary, and you don’t want people being able to download and interrogate it, then Blazor Server is a good choice. The application code is all executed on the server, and only the UI updates are sent to the client. This means your code is never exposed to the client in any way.

TRADEOFFS

• Heavy server load—Where Blazor WebAssembly allows us to utilize the power of the client, Blazor Server does the complete opposite. Almost all of the work is now being performed by the server. This means you might need a larger investment in your infrastructure to support Blazor Server apps. Depending on the size of the application, load balancing may also be required to correctly manage the SignalR-based sessions used by Blazor Sever.

• Doesn’t work offline—Where Blazor WebAssembly takes offline working in stride, Blazor Server does not. The SignalR connection is the lifeline of the application, and without it, the client can’t function at all. By default, this results in an overlay with a message saying the client is attempting to re-establish the connection. If this fails, the user has to refresh the browser to restart the application.

• Latency—Due to its design, Blazor Server apps are sensitive to latency issues. Every interaction the user has with the application must be sent back to the server for processing and await any updates that need to be applied. If there is a high latency in the connection between client and server, a noticeable lag manifests in the UI and actions quickly feel sluggish. In real numbers, a latency above 200 ms will start causing these issues.

• Requires a stable connection—Continuing on from the need for low latency and tying in with the inability to work offline, Blazor Server apps need to have a stable internet connection. If the connection is intermittent in any way, the user will continually see the reconnecting overlay in their application, which quickly becomes very disruptive. An obvious scenario where this could occur is when a user is on a mobile device, which has intermittent connection.