I've never used traditional ASP.NET MVC and started with Nancyfx. I'm considering making the switch to ASP.NET MVC + Web API but have some general questions.
I think I may have been spoiled with Nancyfx but I have some real problems and concerns with it which is why I'm not sure on it for my rewrite. The main problem is the load times. I understand it compiles the Razor views upon first load which extends the load times but there are bugs that cause it to not work (known issues). I've implemented a work-around but I've read that ASP.NET MVC can pre-compile to avoid this situation (Nancyfx cannot).
Doing some research with ASP.NET MVC + Web API it seems the Web API is for the restful endpoints while the ASP.NET MVC is for serving the pages. As you know, Nancyfx combines these two technologies into one which is what is really nice. Am I correct about this or is there a way around to make ASP.NET MVC serve the Razor pages plus serve the JSON/XML requests depending on the request type?
I do not really care to use ASP.NET core to be honest because my application integrates heavily into Active Directory, Microsoft Exchange and other Windows application that are not on other platforms. Someone wanting to deploy it on a Linux server is kind of pointless IMO for what I'm doing.
To put it simply, ASP.NET MVC offers you two controller base classes: Controller and ApiController. You inherit from the Controller class if you want to create view-based controller actions and you inherit from ApiController if you want to create API actions. On the other hand, in ASP.NET Core, you can use the same controller infrastructure to deliver views as well as REST APIs. You can always combine .NET Framework and ASP.NET Core. However, .NET + ASP.NET Core solution works only on Windows about which you apparently have no problem.
Related
Any feedback much appreciated.
I need to create a Web API (ASP.NET Core Web API), which does some basic CRUD operations. Thats no issue at all, and I need to create a simple Angular UI for the Web API as well. Thats also no issue. But is there a way to combine both into a single application ? WebAPI mainly and an optional UI part in Angular than having a second angular solution ? I know there is a visual studio project template where you create a .NET Core Angular Application, if I do that, how would I expose the API at the sametime to other clients as API, while still managing the Angular UI ?
Put in another way, my .NET Core application should be primarily a WebAPI which should work independently and act like a WebAPI, while an optional part of it should have an Angular frontend connecting to the WebAPI.
You can view this as a matter of security for your WebAPI and how you expose connections to it. You can serve your API endpoints under one route, i.e. /api and you Angular application at you site route or host it elsewhere.
If you follow the same practices for exposing the WebAPI cross origin, then your Angular application can consume the API in exactly the same way as any other client would.
Followed #johnny's comment and it works !
All you have to do is compile your angular project and put it under wwwroot. Then you can navigate to your index.html page, set your webapi startup to serve static files and your done
I have an ASP.NET Core (.NET Core 2.2) app structured with the following projects:
API: this is meant to represent a WebAPI (with controllers inheriting ControllerBase)
Services: This contains services which the API controllers utilize to access the database, etc
Database: This contains the usual DB repositories, which the services layer utilize to access the database
Now, I want to add a UI that talks to the API (the MVC part pre-.NET-core). How is that accomplished with .NET Core, where MVC and WebAPI are one of the same thing? Should MVC controllers/models/views be part of the API? Should it instead be a new project that listens on a different port? How does authentication fit in for both (e.g. APIs usually have some token-based authentication, UI apps usually have username/password authentication)? Should the WebAPI and MVC portions share the same authentication like ASP.NET Identity? Wouldn't that tightly couple the two if they use the same database?
Is there some kind of Microsoft or community suggested convention/documentation for how to structure such projects?
How is that accomplished with .NET Core, where MVC and WebAPI are one of the same thing?
In dotnet core MVC and WebAPI can be present in the same project. Everything application is like a console application. You can add MVC services to startup class to make it an MVC application.
Should MVC controllers/models/views be part of the API?
Its better to have different controllers for MVC and WebAPI related functions separately while keeping them in the same folder.
Models - They can be reused for both mvc and webapi. Same for view models and DTOs.
Views - Just for MVC, webapi does not require views.
Should it instead be a new project that listens on a different port?
Yes, you can create a different project for webapi and MVC.
How does authentication fit in for both (e.g. APIs usually have some token-based authentication, UI apps usually have username/password authentication)?
If you use token-based authentication then both web API and MVC will be able to use.
Should the WebAPI and MVC portions share the same authentication like ASP.NET Identity? Wouldn't that tightly couple the two if they use the same database?
If you use ASP.Net Identity with identity server then both MVC and webapi will be able to share the same authentication mechanism without tightly coupling.
I think that you are a bit confused about WebAPI compared to MVC.
You can see WebAPI as simple web services answering http request with data (whatever the data is, it could even include javascript or assets).
EDIT:
So sending "UI" informations is definetly a part of your API and Service project.
On API you will need to create dedicated controller(s) to send back your "UI" part(s).
On Service you will need to create dedicated service(s) to fetch the "UI" informations (their is many way to do this, using Ressources, fetching data on Cloud, etc)
EDIT2:
But nothing prevent you from creating an entirely different solution for UI parts. If you chose WebAPI again, you will still need to enforce the previously mentioned API/Service logic. It's up to you to chose whatever you feel confortable with.
The answer to your question is mostly, "it depends on your tastes" but in my opinion...
Unless you are planning on exposing the API to other applications, keep the API controllers in the same application that hosts the MVC controllers (or Razor Page). When I have both MVC controllers and API controllers I put them under separate folders. I think this is OK, because your controllers should be very thin. I generally put all the business logic (including any necessary data access) in services that are built in a separate class library.
You only add an API if you actually need it.
Do you plan to expose anything to another app?
If all you want is a UI which interacts with a database then don't bother, use the services to retrieve the data, called them from the MVC controllers and skip the API part completely.
You don't need an API for such a limited use case. An API introduces a host of other things to consider, like authentication and security.
Don't complicate things when you don't need to.
I am new to ASP.NET MVC and Web API and trying to get the basics. AFAIK, we have project templates in VS 2013, named as MVC, Web API and Both of them together.
I have gone through the tutorials and learned that we can make an API by using MVC alone as well as with Web API Template.
So, What are the differences between these, based on Architecture and Usage?
Basically, a Web API controller is an MVC controller, which uses HttpMessageResponse as the base type of its response, instead of ActionResponse. They are the same in most other respects. The main difference between the project types is that the MVC Application project type adds web specific things like default CSS, JavaScript files and other resources needed for a web site, which are not needed for an API.
MVC is used for creating web sites. In this case Controllers usually return a View (i.e. HTML response) to browser requests. Web APIs on the other hand are usually made to be consumed by other applications. If you want to allow other applications to access your data / functionality, you can create a Web API to facilitate this access. For example, Facebook has an API in order to allow App developers to access information about users using the App. Web APIs don't have to be for public consumption. You can also create an API to support your own applications. For example, we created a Web API to support the AJAX functionality of our MVC web site.
Microsoft changed the way they present the different templates. Now instead of using different templates for different project types, they encourage developers to mix ASP.NET technologies inside the same project as needed. Microsoft calls this vNext.
UPDATE: For ASP.NET Core, Web API has been integrated into the MVC 6 project type and the ApiController class is consolidated into the Controller class. Further details at: https://wildermuth.com/2016/05/10/Writing-API-Controllers-in-ASP-NET-MVC-6
My two cents...
In ASP.Net MVC – the MVC’s Controller decides what should be the View - i.e., the controller decides what the user should “see” (based on the current scenario or context), when they make a request.
In ASP.Net Web Forms, the ASPX pages decides what the user should “see” when they make a request.
But in Web API, there is no control/power to any of the Web API’s features to decide what the user should “see” when they make a request.
Web API is NOT a technology tied up with websites only. It can be used for multiple purposes – not only websites. So it doesn't know the meaning of rendering
Further Reading
Planning Web Solutions Today: Web Forms, ASP.NET MVC, Web API, and OWIN.
WCF or ASP.NET Web APIs? My two cents on the subject
The Next Generation of .NET – ASP.NET vNext
Getting Started with ASP.NET MVC 6
MVC controller derived from controller class. In Mvc you can returns views. Mvc achitecture uses to create an application. However Web apis are used to provide data to various application.
Web Api drives from Api controller and it doesn't return view.
Note: You can also create Web Api from MVC controller but you need to return result as JsonResult or other web api supported return types.
In addition to answers already provided here, its worth noting any controller which inherits from ApiController and having an action with Http verb POST can only have one [FromBody] input parameter. If using a MVC controller (deriving from 'Controller') you can have many post input parameters.
I've got a simple thing to do - implement the login form. My employer wants me to use Web forms and my stubborn ass want's to implement the MVC pattern (I already have). The problem is I have no idea how to instantiate the Controller. I run debugging, get the view, but since there is no controller (or model), nothing happens when I click login since no one can respond to the event.
Where and how can I instantiate the Controller?
Yes, you certainly can.
I quote:
"As of 2014, the official answer to this problem is using Web API, as explained in this article I wrote for Simple Talk about a year ago.
Integrating a Web API layer into a Web Forms application couldn’t be easier. You just plug in the Web API runtime, configure routing so that you decide exactly which URLs you want to support and start writing your controller classes in the App_Code folder. Web API follows nearly the same programming model as ASP.NET MVC and is really easy to learn. In the end, it’s just like writing controller classes equipped with public methods callable from JavaScript clients.
ASP.NET Web Forms and ASP.NET MVC share the same runtime environment and requests are routed through exactly the same pipeline. It is even acceptable to say that ASP.NET MVC is just a global HTTP handler installed on the ASP.NET request pipeline. If the incoming request matches the URL requirements supported by the MVC handler then the request is routed to it; otherwise it is processed by the runtime as usual. “As usual” here means just as if it would go in a plain Web Forms application."
Here is the source of my above quoted information. I suggest you give this a read, as this is very useful and will give you a good understanding of the differences between both MVC and WebForms, and how can mix the architectures.
I am new to ASP.NET MVC and Web API and trying to get the basics. AFAIK, we have project templates in VS 2013, named as MVC, Web API and Both of them together.
I have gone through the tutorials and learned that we can make an API by using MVC alone as well as with Web API Template.
So, What are the differences between these, based on Architecture and Usage?
Basically, a Web API controller is an MVC controller, which uses HttpMessageResponse as the base type of its response, instead of ActionResponse. They are the same in most other respects. The main difference between the project types is that the MVC Application project type adds web specific things like default CSS, JavaScript files and other resources needed for a web site, which are not needed for an API.
MVC is used for creating web sites. In this case Controllers usually return a View (i.e. HTML response) to browser requests. Web APIs on the other hand are usually made to be consumed by other applications. If you want to allow other applications to access your data / functionality, you can create a Web API to facilitate this access. For example, Facebook has an API in order to allow App developers to access information about users using the App. Web APIs don't have to be for public consumption. You can also create an API to support your own applications. For example, we created a Web API to support the AJAX functionality of our MVC web site.
Microsoft changed the way they present the different templates. Now instead of using different templates for different project types, they encourage developers to mix ASP.NET technologies inside the same project as needed. Microsoft calls this vNext.
UPDATE: For ASP.NET Core, Web API has been integrated into the MVC 6 project type and the ApiController class is consolidated into the Controller class. Further details at: https://wildermuth.com/2016/05/10/Writing-API-Controllers-in-ASP-NET-MVC-6
My two cents...
In ASP.Net MVC – the MVC’s Controller decides what should be the View - i.e., the controller decides what the user should “see” (based on the current scenario or context), when they make a request.
In ASP.Net Web Forms, the ASPX pages decides what the user should “see” when they make a request.
But in Web API, there is no control/power to any of the Web API’s features to decide what the user should “see” when they make a request.
Web API is NOT a technology tied up with websites only. It can be used for multiple purposes – not only websites. So it doesn't know the meaning of rendering
Further Reading
Planning Web Solutions Today: Web Forms, ASP.NET MVC, Web API, and OWIN.
WCF or ASP.NET Web APIs? My two cents on the subject
The Next Generation of .NET – ASP.NET vNext
Getting Started with ASP.NET MVC 6
MVC controller derived from controller class. In Mvc you can returns views. Mvc achitecture uses to create an application. However Web apis are used to provide data to various application.
Web Api drives from Api controller and it doesn't return view.
Note: You can also create Web Api from MVC controller but you need to return result as JsonResult or other web api supported return types.
In addition to answers already provided here, its worth noting any controller which inherits from ApiController and having an action with Http verb POST can only have one [FromBody] input parameter. If using a MVC controller (deriving from 'Controller') you can have many post input parameters.