This question already has answers here:
Mixing Angular and ASP.NET MVC/Web api?
(4 answers)
Closed 5 years ago.
We are currently prototyping a new web-based product.
When we started the project we decided the technology stack would be based on Bootstrap 4, Angular 4 and ASP.Net MVC 5.
As we've progressed through the project we've found that we're not really using Bootstrap as other components (such as PrimeNG) appear to be easier to use and work better with Angular.
One big thing we've noticed - which is the point of this questions - is that we're not using ASP.Net MVC.
We have a Web API layer and all our mvc controller methods are simply calling web api methods and passing data through.
My question is this: Is there any point actually using MVC? I'm starting to think we could just have Angular talk direct to the web api layer as MVC is doing nothing for us in the middle.
Does anybody have any advice as to why I shouldn't do this?
No you don't need MVC at all. You can use any server language you like - either in the form of an API (probably easier) or another GUI framework like MVC.
As you've realised, Angular is just a client-side tool and doesn't care what the back-end is - it just makes HTTP requests and receives the responses, completely agnostic of the code which was used to generate those responses.
In fact, that's one of the beauties of the web - communication between browser and server is entirely done using agreed common standards (principally the HTTP protocol, supported by things like JSON), allowing an almost limitless combination of server- and client-side frameworks to work happily together so long as they both adhere to those standards.
You would use MVC in the case that you want the angular application to be server rendered and then served to the client. Other use case where you can force this is when you want the base code to be together and deployable from one project and not two, in the case that you have one project for webapi and another for the angular application.
In this last case, deploying two different projects will have the advantage that your angular app will be completely agnostic of you backend, this means that you just need to change the endpoints of your services and bam! Running app, no? Well not really, the contra is that you will need to configurate all the CORS related crap to it so that you client can communicate with your backend.
HTML helpers is the answer to your question(it really helps). Another advantage is that it provides better coupling with model and validation.
To clearly answer this one would need to understand how back-end works. You would need to understand how html-helpers connect with the backend and help bring in clarity in development. Also for testing purpose ASP.net MVC + Angular is a better option.
So this decision(to use MVC.Net) is unlikely to come from a UI developer but from an architect who has various challenges to answer.
1) conformity with front and backend(better communication/ isolated development)
2) improve code reuse
3) validation when and where (boundaries)
4) type safety
5) easiness in bringing in new developers
6) testability
Related
Is there a way to convert an Angular 2 C# MVC application to have single page functionality or is that somewhat unrealistic?
The web application that I am working on is rather large and contains roughly 15 different components. The routing is all set up at this point. Is single page worth looking into or does the size or the sight put it out of scope? If so, how would I go about beginning to incorporate this feature into my project? I am not asking for a step-by-step tutorial rather to just be pointed in the right direction.
Angular 2 is a single page (SPA) framework. So if you are using Angular 2 with MVC then you already have some SPA functionality. Maybe your MVC is serving up pages and each page has a different instance of an Angular 2 app. If this is the case and you would like to consolidate to just a singular Angular 2 instance, then you would need to either convert the MVC app into a Web API or add API endpoints for Angular to consume.
Unfortunately, I can't speak to whether or not this is worth it for your project. I would recommend doing some research on the benefits of a single page app to see if they align with your goals.
(First i just want to say i'm sorry if its not worded the best but i have been researching for hours and i thought maybe someone on here could clear this up for me)
Im new to creating web apis and i have been googling just doing some research and i have built a few MVC applications just to get exposed but i never really thought of making an API for it until today. One of the reasons its listed to be useful is it allows your application to be used across tablets and smart phones etc. What im not understanding is how you would do this as in would you just add something to the API so it makes it compatible for all browsers or if i need to re build it using Web API instead of MVC.
Thanks,
I think your looking at a Web API from the wrong perspective. It's not really about compatibility necessarily, but rather about the ability to reuse the code/back-end functionality.
So rather than having your dependencies all wrapped up in one MVC project, the references are external. This allows for essentially the same functionality across multiple projects as long as the request are being handled in the same manner.
I have a very large asp.net MVC 4.0 application that I'd like to start migrating to Web API with asp.net 5.0 and Angular 2.0.
The main reason is to start future proofing and setting up some new components into a more modern SPA architecture.
My plan is to have a small section of the existing site which when routed to displays an Angular SPA app calling Web API for data, instead of the MVC controller and functions. For this section, I'm not planning on using ASP.NET MVC features such as the shared layout page, bundling, routing etc, preferring to instead leave this to angular.
Both my existing MVC and new Web api projects will be using the data layer project/repository which uses EF.
My questions are:
How does this sound? I couldn't find much literature on how to introduce angular into an existing app
Should I use separate projects, or a whole separate solution on a new domain which accesses the same db? Ie, rather than migrate, start a new solution on ASP.NET 5.0
How to I handles authentication and authorisation? I'm using Identity v2.0, can I mix that so that users accessing pages on the MVC site use standard forms based authentication, but when accessing the Angular/ API portion they use tokens?
Thanks for your time.
We've been in this process for last 6 months (the only difference is Angular, rather than Angular 2). And here is my opinion...
a small section of the existing site which when routed to displays an Angular SPA app calling Web API for data, instead of the MVC controller and functions
Extremely difficult, if not impossible, since ASP.NET Core is fundamentally very different from MVC 4. I would suggest to have a separate site (on a different port) that runs Core and Angular.
I'm not planning on using ASP.NET MVC features such as the shared layout page, bundling, routing etc, preferring to instead leave this to angular.
That was our first approach, but in order to accomplish it, we would need to pre-load a lot of Javascript libraries, or do smart things for dynamic loading. It is easier in Angular2 (SystemJS that allows dynamic loading is built into the infrastructure). Instead, we split the application into about half-dozen features. Each feature has a .NET controller and a single view (Index.cshtml). Within the feature we use Angular capabilities for routing, views, etc. This approach also helped us to have strongly typed views.
Should I use separate projects, or a whole separate solution on a new domain which accesses the same db?
Entity Framework is also quite different. In our old (very old) solution we didn't use EF at all, so it was an easier decision. But even if you do use EF in current solution, EF Core is also a different animal, including the way it does migrations. It was much easier for us to have a clean cut.
How to I handles authentication and authorisation?
Our old system was using membership framework, and we didn't have anybody on the team familiar with OAuth. So, while waiting for IdentityServer 4 (that currently has almost no documentation), I suggest you consider SaaS solutions like StormPath or Auth0 (we love StormPath). If you have experience with IdentityServer, you may jump into IdentityServer 4. Since we are using MVC, our authentication is very straightforward; but I think AJAX-based authentication wouldn't be that much more difficult.
Hope that helps. SO doesn't like "opinion-based" questions - but I think there are a lot of teams struggling with this type of transition, and hopefully, this question and answer are appropriate :)
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I have some experience in the three technologies, MVC, Web API, and AngularJS.
But I used MVC + jQuery alone, and Web API + AngularJS alone.
I found some articles about mixing MVC + AngularJS, but actually I didn't get the point: why do I need to mix them?
So my question now:
- What the pros and cons of mixing "MVC + AngularJS" over "Web API + AngularJS"
Edit: How to get the best of all worlds by mixing MVC +Angular? Or by using Web API +Angular I will not miss anything (which is what I think is the case)? Or what will I miss from MVC if I decided to go for Web API + Angular alone, especially when I am targeting SPA?
The main advantage of using MVC + Angular over Web API + Angular is that your server can directly manipulate the html markup within a view before sending it to the client. In the case of Web API, the server only produces a json serialized model and the view is fully Angular's concern.
Another reason to prefer the MVC approach would be if you do not wish to make use of the full range of Angular capabilities. For example, you might choose to use MVC for routing rather than the Angular route provider.
A disadvantage of the MVC + Angular approach is that your html markup will contain mixed angular and razor code. This will probably make it less readable and any person working on it will have to be able to work with both languages.
Also, if you end up using only a small subset of angular, it might be a good indication that you could have used a simpler javascript framework instead. For example, if you only use model binding, you could use Knockout.
Finally, you might consider using both MVC and Web API along with Angular in an effort to get the best of both worlds. You could for example use MVC views for SEO related markup and use Web API for exposing your model.
I am not sure questions like this have correct answer cause most times used technologies are bound to specific business requirements.
If you are developing back-office web application, accessible only for registered users(or small group of people), using WebAPI + Angular increases overall user experience in terms of speed, performance and responsiveness.
If you are developing a website which is dedicated mostly for 'guest users', needs SEO, needs to be indexed, has complex usability requirements etc. you should forget about whole cool stuff connected with Single-Page-Application(I believe most WebAPI + Angular apps) and switch to tools which enables you to fulfill specific needs.
I don't think you should consider differences between MVC + Angular vs WebAPI + Angular - the question is to use Angular in addition to MVC + jQuery app. If you have a lot of logic in your views(not business logic of course) and want to avoid binding data to whole bunch of jQuery objects, require Angular and make your life easier. Angular core doesn't have any routing functionality so saying that it can be used only with SPA/SPI application is a bit stupid.
For most of my projects I use jQuery to manipulate DOM and Angular to manipulate data.
You could indeed go for just WebAPI + AngularJS. If you start building from scratch, there's no need for MVC. You can just serve up a static index.html that fires up your AngularJS application and take it from there.
I've done projects like this in the past, but also have done project where we also decided to have an MVC app with AngularJS and WebAPi. With that we created several SPA's within the webapp. I think I've heard the term 'pockets of SPA' somewhere probably in .NET Rocks!.
So in case you need to display static data, just quickly throw something together in MVC. If there's a page that uses a lot of user-interaction, serve it up with a simple controller + view and hook up all the behavior through AngularJS and WebApi.
In short: it allows you to use 'best of both worlds' approach, where you can quickly display static data using MVC, and leverage AngularJS in case you have a very interactive page.
Does anyone have experience using ASP.NET MVC project as a Web Service?
i.e. using ASP.NET MVC without Views, so other applications can use the URL to GET or POST to the actions in the Controller.
Has anyone used it? If so, are there any drawbacks for not using Web Service project instead?
Thank you all in advance!
It really depends on the kind of application you're writing. I would actually argue the inverse of LukLed's position - SOAP-based services are better suited for internal clients when you want to support things like Windows Authentication, or different protocols like TCP or MSMQ.
Using a more web-style of GETs and POSTs around specific "resources" starts to get you into the REST architectural style. This technique has a few distinct advantages to me:
The response is usually smaller, particularly when using lightweight formats like JSON
Because of the simplicity of the requests and responses, this makes it much easier to use in mobile / native applications (see Twitter's API, for example)
The service you create can be self-describing and discoverable, because you can link to other parts of your API just like normal web pages.
One article that particularly helped me understand the tradeoffs here is Martin Fowler's "Steps Toward the Glory of REST." That being said, it may or may not be the right fit for your application.
If you do choose to build a more REST-based service, definitely consider using the ASP.NET Web API built into MVC4 as others have mentioned. It's currently in beta, but Microsoft felt good enough about it to give it a go-live license.
UPDATE:
Since ASP.NET core, ASP.NET web API has been integrated into MVC 6 project.
https://wildermuth.com/2016/05/10/Writing-API-Controllers-in-ASP-NET-MVC-6
If you want to use simple GET and POST calls, MVC will be good choice. ASP.NET MVC 4 will have support for creating HTTP based APIs. You can read about it here: http://www.asp.net/web-api
Web Service created in Web Service project can be easier to consume, because it can generate WSDL file, that can be easily read and used in many different languages (by using SOAP protocol). On the other side, WS can create huge XML responses, that could be many times smaller, if you used your own format.
If you want to spread your web service around the world, allowing SOAP will make life easier for many developers. SOAP can be used by people, who almost have no idea about programming. If you'll use it internally, prefer speed and simple requests and responses, you can use MVC.
New ASP.NET MVC includes Web Api Kit, which can do exactly what you want. With current version you can still use it. There are no real drawbacks to it