I am new to AngularJS and need some advice on how to structure a SPA with Web API for an internal order entry system (SEO not a concern). I would like to set this up in a clean, well-structured fashion for efficient development, debug & deployment.
Here is what I am planning to do:
Not use MVC / razor views (leave all routing and rendering to Angular)
Create two separate Visual Studio (2013) solutions: one just for the AngularJS SPA portion and one for Web API portion (for serving all data to the SPA).
As an alternative, I guess I could use one Visual Studio solution for the full site (both SPA and WebAPI) and then use razor to serve the html files (or figure out how to disable the default MVC plumbing and serve straight HTML instead, to avoid the MVC overhead). Also, would I then have to put both the SPA and the WebAPI in the same project to be able to debug with Visual Studio easily?
Or perhaps there is a better approach?
Advice on best practices / good approaches on this would be appreciated.
We have created a two different projects under the same solution , First one is the empty web application and the next one is a class library .
1) Web application project consists of angular JS and the other client side components .
2) Class library consists of the Web api controllers and the relevant components such as filters and the other details.
We have a bootstrap class in the class library project which bootstraps the webapi and the container for us. Also it makes the testing of Web api easily
public class Bootstrap
{
public void ConfigureRoute(HttpConfiguration httpConfiguration)
{
}
public BootStrapApplication ConfigureContainer()
{
}
}
From the global.asax in the app_start we call the BootStrap application class and the method .
For application structure on angularjs i found the John papa guide efficient https://github.com/johnpapa/angularjs-styleguide
Hope this helps
Related
I maintain an ASP.NET MVC web application that uses the conventional MVC architecture except for any route that starts with /admin, which is handled by an older WebForms architecture. The MVC and WebForms code coexist in the same .NET 4.8 Framework project, and the user of the site can't even tell there's any difference, because the styling is the same and we use url prettifying tricks so that you can request /admin/something rather than /admin/Something.aspx.
This all works fine, except that WebForms is really showing its age and now we want to port the admin stuff to Vue. But I can't figure out how to deploy Vue such that it has the same coexistence with MVC.
I know that I could continue to use Razor pages and add Vue with a script tag, progressive enhancement style, but I think that makes it impossible to use single file components, which is one of the Vue features that seems important.
It seems like the most functional way to use Vue is to create a proper Vue site, with build step tooling, but how can I do this within an existing MVC project and just delegate one route to the new code, and port other routes over as needed?
I have finished building my first durandal application using .Net MVC and Web Api v2, every thing working fine however I noticed that I can access files directly like
http://localhost:1990/App/views/sessiondetail.html
now I don't want that cuz that is just requesting static pages with no logic or styling.
You will have to override the web servers' default configuration for handling html files in your application, thus tying into to whatever security mechanisms you have in place for request authorization.
This article how explains how to add a handler for all *.html files in your application.
I'm creating an application with a .Net Web Api project wanting to use pure AngularJS as the client side. Since Web Api is built on top of MVC, it creates MVC specific and default items that I feel is not needed. These items include the HomeController, _ViewStart.cshtml, _layout.cshtml, etc. I tried removing them but it comes up with errors. Has anyone tried to remove the MVC stuff out of the web api project and used separate client side front-end? Is it even possible to remove the MVC items without errors?
Remove RouteConfig.cs from App_Start, remove the Views directory and all sub-directories including the Views internal web.config file. Comment out or delete all the lines in the Global.asax.cs Application_Start method except GlobalConfiguration.Configure(WebApiConfig.Register). Remove the HomeController, add an index.html and any needed Angular scripts and go at it. I also added solution folders to organize my views as reusing the existing Views folders did not work. I'm using VS 2015 but is should work for 2013 also. PWE
Web API is not built on top of MVC.
The default templates bring in MVC for the sake of supporting a help page, but you don't need to use it.
You can start with an empty web project and just check Web API.
The routing piece is server routing and it's part of what maps the URL to Controllers+Actions, it has nothing to do with Angular routing.
As Mike Cheel alluded to, there are no dependencies between MVC and Web API. However, if you use the built-in templates, it's easy to get the impression that the 2 are linked. They include a lot of stuff in these templates because they can't anticipate where you want to go with your project... so they try to cover all the bases.
For your purposes, you would probably be better off to start with an empty project and add only the components that you actually need. For this approach, some of the best tutorials and starter projects are from Taiseer Joudeh's "Bit of Technology" blog. His tutorials helped me to build an "MVC Free" web application from scratch that uses JSON Web Tokens and AngularJS Interceptors for security and Web API 2 and Entity Framework to serve up the data.
He has many tutorials on his website... but you might want to start with "AngularJS Token Authentication using ASP.NET Web API 2, Owin, and Identity". What what.. you didn't ask about security? Well... security is an issue that you will need to confront at some point anyway... and Taiseer presents a nice solution for securing an Angular/Web API application.
All the action is client side in a SPA app. The Visual Studio Durandal and Hot Towel project templates both serve the SPA out of an ASP.NET MVC application.
What, if anything, does the ASP.NET MVC infrastructure bring to the party? As far I can see all it does is make it hard to serve a WCF Web Service (ajax enabled) out of the project web.
Yet both of the project templates are set up like this. What have I missed?
As a matter of fact, ASP.NET MVC in this template is not necessary. All it does is serve the initial Razor template for the SPA and provides you with the bundling and optimization support of all the client side javascript resources for the application so that when you deploy your application you don't end up with gazillions of HTTP requests from the client to fetch all the .js crap necessary for the application to work. Of course you could perfectly fine have used the bundling feature outside of ASP.NET MVC in a simple and plain ASP.NET web application.
What, if anything, does the ASP.NET MVC infrastructure bring to the party?
See the documentation:
Hot Towel builds on the familiar and powerful ASP.NET MVC structure.
App_Start
Content
Controllers
Models
Scripts
Views
As far I can see all it does is make it hard to serve a WCF Web Service (ajax enabled) out of the project
You can't just right-click your project and add a new WCF Service?
I have an old web forms application (.net 3.5) hosted at www.business-app.local
I want to build a new ASP.NET MVC (.net 4.0/4.5) application that will also have the domain name www.business-app.local
I know I can't have two applications with the same domain and port on IIS.
I have tried adding the MVC app in a virtual directory but hit a bunch of web.config clashes.
I want to keep the two applications separate, i.e. it is not a solution to just add the web forms pages to my MVC application, or to add MVC to the web forms application.
How can I achieve this using IIS 8?
The easiest way to do this is to create your new MVC app and add the folders containing the webforms into it. Queti mentions doing this the other way around, but honestly, it's a massive PITA, as you have to hack around with config files and references.
Once you have your webforms pages in specific folders in the MVC app, simply add exclusions for them from routing in global.asax.cs like so:
routes.IgnoreRoute("Webformsfolder/{*pathInfo}")
Also, seeing as you are (I presume) phasing out the webforms stuff eventually, it's probably best to start from scratch anyway, IMHO. Good luck!
You could add MVC to the current application. The trick is to make sure that the routes do not conflict with the web forms directories otherwise the WebForms will be the ones that handle the request.
This is the process I've followed when migrating Web Forms sites to MVC.
I have had to compromise and put them two apps on separate sub domains with a common cookie.