We want to build an asp.net core web application. it contains MVC part for returning Views and API to return JSON and have Restful services for our web application.
So can I have MVC and Web API inside the same project? as currently when i want to create a new project inside .NET 6.0 i have to select the either MVC or Web API type :-
So can I have MVC and Web API inside the same project? as currently when i want to create a new project inside .NET 6.0 i have to select the either MVC or Web API type :-
Certainly you can. What all you need is, you should have one solution. Furthermore, within the solution, you ought to create two project. One for MVC application and another for Web API application. Here is the simulation how you can achieve that:
Project Architecture Would be Like:
If you want to run two project together:
Go to your solution and right click on it
Select Property
Choose Multiple Startup Project
I'm confused whats different between Razor components and Blazor and which is better and in the last release .NET Core 3.0 Preview 3 the add those to Razor Components
Razor Components improvements:
Single project template
New .razor extension
Endpoint routing integration
Prerendering
Razor Components in Razor Class Libraries
Improved event handling
Forms & validation
Essentially there are 3 parts to understand.
Razor Components
This is the name for the core, out of process, component model which was created back in July 2018, for the first release of Server-side Blazor.
Razor Components is the core of the framework and contains all the following things.
Parameters
Event handling
Data binding
Routing
Dependency injection
Layouts
Templating
Cascading values
Server-side Blazor
This is the server-side hosting model, running on ASP.NET Core, for Razor Components. This version hosts the Razor Components model on the server. It uses a small runtime to send UI events from the browser to the server. Once processed by Razor Components, any UI updates get sent back from the server to the browser and the runtime handles updating the DOM. All this communication is handled via a SignalR connection. Even JS interop calls are handled this way.
Client-side Blazor
This is the client-side hosting model for Razor Components.
In this model, everything is hosted in the browser. Mono, compiled to WebAssembly, is the .NET runtime. On top of this sits Razor Components and then finally the application.
The great thing about this architecture is that any feature added to Razor Components should, in theory, be available to both hosting models. Although in reality, this is not always the case.
What's better?
That very much depends on what you want to do.
Client-side Blazors biggest drawback is its download size. This alone could rule it out for many developers. Downloads are easily into multiple MBs which if someone is trying to view your app on a mobile with a slow connection, they are not going to have a great experience. However, it's worth noting that after the first download a lot of the content is cached so subsequent loads can be a few 100kb.
Client-side Blazors debugging experience is very primitive right now as well. Which means working on it as a developer can be challenging at times.
Server-side Blazor has a much nicer developer experience in terms of debugging. The app is much faster to download and only has a size of a few 100kb before any caching takes place.
The downside is potentially scalability. But this will very much depend on the number of concurrent users you are expecting. Because this model uses SignalR your app will have a top limit on concurrent connections. But, you can manage this by plugging into Azure SignalR to allow a far greater number of connections to your app.
Ultimately, both hosting models of Razor Components have a long way to go. The authentication stories for both are in very early days, although client-side Blazor is arguably in a better place. The routing engine is still limited, forms and validation have only just had it's first release and there is still work to do.
Another thing to keep in mind is that it is possible to swap between the models pretty easily. So whatever decision you make you're not tied into it. There will even be a way of doing this built into the framework at some point so nothing you do now will be wasted.
Any questions, please ask. But I hope this helps.
Razor Components is a framework with which you can create SPA web applications. It is divided into two mode of execution. When the web app is hosted and executed on the browser, it is called Blazor. Blazor applications are written in C# and compiled into .NET assemblies. They are executed and run on the browser as .NET assemblies by the Mono run time, which itself is compiled to Web Assembly.
The second mode of execution is server-side. That is, your web app is executed on the server, not on the browser. Note that here the runtime environment is not Mono Web Assembly but the Asp.net Core run time. This is called server-side Blazor, but the term Razor Components is used as well, so that the confused get perplexed. The reason for this is historic: At the beginning, there was only Blazor running on the browser. But then came the idea that a web app can run on the server, and only the diffs can be send to the browser by means of SignalR. Running the web app on the server is much easier than running on the browser, and the developer can use many elements he can't use on the browser, such as debugging, etc. As a result of this possibility, the Asp.Net renamed the Blazor framework as Razor Components, which you can treat as a super structure on which Blazor is built. This is why the confusion. Let's emphasize this division as follows:
Razor Components --> Blazor (front end; browser)
Razor Components --> Razor Components (server-side Blazor )
I know this is a source of confusion, but this is it...
As to the question which is better, I may only say that it depends exclusively on your requirements. Each of these mode of executions has its benefits and drawbacks. Blazor applications are more suitable for running on the internet as public web sites, whereas server-side Blazor application are best used on the Intranet as enterprise web sites.
The list you displayed is related to Razor Components framework. Some improvements, for the time being, may only be relevant to Blazor, others to server-side Blazor. There is only one way to know which is which: To learn Razor Components. It takes time to learn it, less than Angular, especially if you are a .Net developer, but it is still something which requires some investment.
Hope this helps...
I'll improve on it later on, but if you have specific question don't hesitate to ask...
You have every right to be confused, the naming has changed a lot and when you wrote the original question the Blazor team had recently renamed 'Server Side Blazor' as 'Razor Components'. That has thankfully since been abandoned, see the timeline below for more on that.
To anyone finding that the naming conventions in the answers here don't seem to marry up with what they are reading in older blog posts it's worth knowing that the meaning of 'Razor Components' has changed repeatedly over time.
This may also help anyone like me who has been using Blazor since near the beginning and feels sure that the names have changed!
TL; DR
The naming has evolved a lot during the pre-release period. Kudos to the Microsoft and the Blazor team for trying to come up with clear names and being willing to change back when needed. However, this has left a legacy of mixed naming conventions in older articles and some Blazor veterans sometimes use older naming conventions.
At the time of writing in September 2020, with Blazor at version 3.2, the official naming convention is:
Blazor Components (formally called 'Razor Components') can be used in...
Blazor Server apps, or ..
Blazor WebAssembly apps
The exciting history of Blazor naming
October 2018: 'Razor Components' becomes the new name for 'Blazor Server Side'
When Blazor 0.6.0 was released it was decided to officially name server side Blazor as 'Razor Components'.
Dan Roth discusses that in his Blazor 0.6.0 experimental release now available blog post in October 2018:
We announced last month at .NET Conf that we've decided to move
forward with shipping the Blazor server-side model as part of ASP.NET
Core in .NET Core 3.0. About half of Blazor users have indicated they
would use the Blazor server-side model, and shipping it in .NET Core
3.0 will make it available for production use. As part of integrating the Blazor component model into the ASP.NET Core we've decided to give
it a new name to differentiate it from the ability to run .NET in the
browser: Razor Components.
It's also discussed more in the ASP.NET Core updates in .NET Core 3.0 Preview 2 blog post.
Feb 19: Naming is hard...
Probably due to confusion that was arising, the Razor Components name for Server Side Blazor was expanded to 'ASP.NET Core Razor Components'. This is mentioned in the Blazor 0.8.0 release notes:
Server-side Blazor is now ASP.NET Core Razor Components in .NET Core
3.0 As was recently announced, server-side Blazor is now shipping as ASP.NET Core Razor Components in .NET Core 3.0. We've integrated the
Blazor component model into ASP.NET Core 3.0 and renamed it to Razor
Components. Blazor 0.8.0 is now built on Razor Components and enables
you to host Razor Components in the browser on WebAssembly.
April 2019: Switching back to Server-side Blazor
In April 2019 Blazor server side went into official preview and as part of that the naming for server side Blazor was switched back:
Simplifying the naming and versioning
For a while, we’ve used the terminology Razor Components in some cases, and Blazor in other
cases. This has proven to be confusing, so following a lot of
community feedback, we’ve decided to drop the name ASP.NET Core Razor
Components, and return to the name Server-side Blazor instead.
This emphasizes that Blazor is a single client app model with multiple
hosting models:
Server-side Blazor runs on the server via SignalR
Client-side Blazor runs client-side on WebAssembly
… but either way, it’s the same programming model. The same Blazor
components can be hosted in both environments.
Note that in the above description there is no mention of Razor Components at all, now we have two different Blazor hosting models (Client-side and server-side) as ways of delivering Blazor Components to the browser.
Sept 2019 The return of 'Razor Components'
Dan Roth's Blazor and .NET Core release notes for the next few versions no longer mention the term 'Razor Components' at all until .NET Core 3.0 Preview 9 when the term emerges again in the name of the 'Razor component unit test framework prototype'.
May 2020 'Razor Components' = 'Blazor Components'. Introducing 'Blazor Server' and 'Blazor WebAssembly'
By the time we get to May 2020 Razor Components and Blazor Components are now being used as synonyms for each other and the naming for the two hosting models has evolved.
The Blazor WebAssembly 3.2.0 now available blog describes that as follows (my emphasis):
Blazor components can then be hosted in different ways to create your web app. The first supported way is called Blazor Server. In
a Blazor Server app, the components run on the server using .NET Core.
And...
Blazor WebAssembly is now the second supported way to host your Blazor components: client-side in the browser using a WebAssembly-based .NET
runtime.
So.. the term 'Razor Components' is officially dead, right?
It would be so much easier if it was.. it does seem like 'Blazor Component' would be a more natural fit. But no, from the Components section of the official documentation:
Components in Blazor are formally referred to as Razor components.
I know that Asp.Net MVC and Asp.Net Web API were merged into one code in Asp.net Core and they inherit from Controller base class and can all return implementations of IActionResult. it be a View for MVC or Json for web api.
But when i want to create a Asp.net Core project, it offers two templates (Web Application and Web Api ), according to what i said in above, there is no differences between these controllers, why there is two templates? is there any differences that i don't know about it?
The web application template will create folders and import stuff needed for a web application such as jquery, css etc. Web api template will create folders and import stuff for a web api. Also the controllers created by default will have different implementations, for example, web application will be returning views and the views will be created in the appropriate folder.
So although they derive from the same controllers, each type of project requires different dependencies.
If I were you I would go ahead and create one for each type and see the difference.
If you want to have both web api and web application in the same project, use areas. This way your web and api will have separate controllers, folders and models. Also if you want to separate them in the future, it will be easy to do so.
The difference between 2 templates is-
The WebAPI template starts with a Controller class that will allow you to respond to RESTful requests at the /api/Values endpoint.
The Web Application template will give you an MVC framework enabled project with some Razor views, the bootstrap CSS framework and jQuery library installed.
If you want to create project with both MVC and API controllers then I would suggest to go with ASP.NET Core Web Application template and add require dependencies.
i need few reason for which people mixed ASP.Net MVC and web-api in same project. when we can develop a full project in mvc only then why web api need to include. also we can host webapi project separately which can server request to MVC and other devs or mobile devs etc.discuss the reason and advantages.
some one answer :
We have recently built a project within MVC and WebApi, we used the WebApi purely because from a Mobile Apps perspective. We allowed the mobile dev guys to call our methods within our MVC application instead of them having to go and create the same function.
WebApi allows to create services that can be exposed over HTTP rather than through a formal service such as WCF or SOAP. Another difference is in the way how WebApi uses Http protocol and makes it truly First class Http citizen.
still the above answer is not clear to me and i think this is not the reason for which people mixed ASP.Net MVC and web-api in same project.
so anyone mind to discuss the actual reason and advantages with example scenario.
thanks
Each have a purpose. Most of the time it's usually caused by legacy code. I know we included documentation which used MVC, but we're fully webapi.
FYI, was MS's auto documentation for WebApi ironically.
I am working on an MVC4 application that uses MVC controllers and it is already in production. But a new requirement is to expose some of the functionality as a web service so it is accessible to get/post data programatically by other applications. So I am thinking of introuding WebAPI in this application and use it to provide an iterface to external world as well as use the same service by the views in my application.
My question is how can I use WebAPI in my existing controllers so that I can return Views instead of raw Json data.
Thanks