I'm new to .net, C# and currently write my first Blazor(servcer-side) app. Later i want to migrate to Blazor webassembly..
However, I came to the question, do I need controllers?
I know Controllers in the form of NestJS - that Controllers handle http requests and use Services for data exchange and other tasks.
But because currently everything is handled server-side no http requests are made.. So I can't think of a case, where this (division) could come handy..
Do i misunderstand or oversee something?
And furthermore, are Controllers used in WebAssembly Blazor apps, where actual http requests are made?
Because here I can imagine that such a division is advantageous.
Thanks in advance.
CodePudding user response：
Every time you browse to a website, you are making an http request. Asp.Net has two main ways of processing the request and returning a response:
- Pages (Blazor)
- Controllers (e.g. MVC, or api controllers)
You can use either one of these approaches alone, or you can run them both together. A simplified description of the server-side Blazor pipeline:
- Decide which page the request is routed to
- Deserialize the body and query parameters, based on the C# class for that page
- Instantiate the page
- Execute the handler method on the page
- Render the page
- Return the rendered page as a response
The Controller pipeline is very similar:
- Decide which controller action the request is routed to
- Deserialize the body and query parameters, based on the C# controller and action
- Instantiate the controller
- Execute the action (this might involve rendering a page)
- Return the result of the action (this could be html, or it could be json)
If all you are ever doing is rendering pages server-side and interacting with them, then you can do this entirely through Blazor, with no need for controllers. This is not the main selling point of Blazor, server-side rendering has been around for a while. The interesting part is that you can change the hosting model to Client-side and still achieve this! The client maintains a connection to the server, and sends events when the user interacts with pages or components, but Blazor handles all the details for you. This does come with overhead - every time something on the UI needs to be updated, the server has to send that UI to the client. If you want to remove that overhead, and just send the raw data, then you would need to create api controllers.
I suggest reading through these pages for more information:
CodePudding user response：
By default, the Blazor Server App template is created with services... It's actually a single service that provide the data to the FetchData page. Unless your application is actually the default app as is (you want to impress your girl friend), or a small internal corporate site, I believe that using services is fine. But if your application is going to have public face, it is expected to grow, scale up, be connected to partners, mobile phones, etc., the right way to do that is to create a Web Api project which exposed protected (requires authentication and authorization) end points (Controllers' actions or methods).
By default, the Blazor WebAssembly App template is created with Controllers... It's actually a single Controller that exposes an end point that provides the data to the FetchData page. Unless your application is actually the default app as is... I think it is a good idea to create a Web Api project ( as described above ), and to remove the Controller file. Is it a good practice ? I think it is, though there are some developers that may claim that there is nothing wrong in having your Web Api end points in the Server backend App. And not only that, but that it is preferable. I had once a heated discussion with an OP about this, so you may hear different views according to experience, knowledge and personality.
However, there are many reasons to create a separate Web Api project instead of having Controllers in your hosting backend project. One does not have to be a web developer to understand it.
I'd advise you to always create a Web Api project. If you create a dedicated Web Api project, you can access it from both flavors of Blazor. No need to migrate services defined in Blazor Server App when you migrate to WebAssembly App, even the same means of communication between your app and the Web Api do not change. You use HttpClient service... And you can access the Web Api from mobile apps, Mobile Blazor Bindings, and more.
Another good practice is to bundle your components in an RCL library, and access them from Blazor Server App, Blazor WebAssembly App, Mobile Blazor Bindings, etc.
I guess that by now the path to migrating from Blazor Server App to WebAssembly App is clear to you, and should be easy.