I have a Razor Pages project to serve up some web pages. I will also need a backend to support a REST API that may be called from multiple environments (aforementioned razor pages, desktop apps, iPhone apps, Android apps, etc.). I could add MVC Controllers to the Razor Pages project, or I could add a separate MVC project to the solution. Which is preferable from a software design perspective?
Obviously, if I wanted to host my API separately from my web pages, then that would infer separate projects. However, in my case this is not a requirement. Additionally, having separate projects that both need to launch on startup complicates things due to the restraints of CORS (Cross Origin Request Sharing) as well as the need to add authentication to two places.
Related
I originally programmed two separate. NET applications (1 WebForm and 1 MVC 5) that originally were going to be on separate domains. I'm now trying to integrate both applications on a single portal on a single domain that will likely be a MVC Web Application. Ideally I would like to use subdomains to keep them separate.
I've figured that there's 2 options to make this happen but even then I don't know if #1 is even feasible.
1) Host each application on separate subdomains (ex: WebForm.domain.com and MVC.domain.com) while having the main portal on the default domain (domain.com).
2) Rewrite the WebForm application into a MVC application and just merge the two projects.
I'm open to any and all suggestions
I have an MVC application that uses MVC Controllers to return views. Now I want to expose an API to other applications to consume, as well as returning JSON data types for some SPA features in the same MVC. What are the differences between adding Web API Controllers to my MVC Project vs adding a whole new Web API Project?
returning JSON data types for some SPA features in the same MVC
For that case, I'll place Web API inside existing MVC. By doing so, you can share business logic, services and even models.
In my case, I have SPA silos using AngularJS, and both MVC and Web API live happily in the same web application, and share business logic and data access layers.
It is worth noting that you can share Authentication cookie if you keep MVC and Web API together. Otherwise, it is pain in the neck to authenticate in both places at the same time, because Web API is token based and MVC is cookie based by default.
FYI: In new ASP.Net MVC 5, there won't be separate MVC and Web API anymore.
The only difference between the two is reusability and good design practice. I highly recommend to use it in a separate project. Then, later on, you will be able to reuse it without much or any effort.
Another advantage to segregate is the impact on testing required for any changes made. If you keep the projects different then if later on you change anything, the domain for the re-testing efforts would also be just the second project.
I am quite perplexed over the use of Web Api in a MVC application being developed at my company.I recently joined the project and wondering why they are using this.The application uses JQuery AJAX functionality to pull data for each Tab in a MultiTab Page without refreshing it.
The application here is neither providing data service nor consuming any Web API service.This can be easily achieved without using REST verbs.It is directly connecting to database like a typical web application.
I am holding back myself to raise this question with the team since I haven't used Web API much but has a conceptual idea.
Am I missing something here ?
Microsoft's Web API MVC technology is typically used for external components to interact with the system - not generally a requirement for a standard MVC Web Application.
With that said, I'm not perfectly clear on the architecture. A few points of note:
jQuery AJAX is a perfectly valid (and usually preferred) method to retrieve information for tab pages - it provides a SPA (Single Page Application) "feel" to the site and generally improves performance all around. This does not mean that they're using a Web API
MVC is a framework used for many web applications, including Microsoft's Web API projects as well as ASP.NET MVC Web projects. The use of MVC doesn't mean that they're using a Web API.
A RESTful approach isn't just for Web APIs. Indeed, many find it a cleaner approach when using regular MVC Web Applications, as it tends to be more semantic to what actions are actually being performed (GET to get a view, POST to post data, DELETE, etc.) There's no real reason not to use REST verbs (which are actually just HTTP verbs, but called "REST" when we use them in a certain way). The use of HTTP verbs doesn't mean that we're using a Web API.
To conclude, The MVC Web API framework is it's own technology that's similar to MVC Web Applications, but more geared towards working with non-visual requests and responses, instead tailored to programmatic interfacing.
If this is indeed a Web API being used and not a case of MVC practices that you happen to be unfamiliar with, then yes, I think it's a good question to raise (at least from a technical standpoint - politically, maybe not, but we can't answer that for you).
A typical setup is to have multiple projects, one of which is a Web Application, which makes use of shared project(s) for domain/business classes and data persistence. Additionally, a Web API project is often used to provide access to the system for external components, but this is a separate "presentation layer" project from the aforementioned Web Application.
There may be cases where a Web API application is written as the core interface between the internal system and the rest of the outside world, where the MVC Web Application then interacts with the Web API, but this is a corner case that should only be done with specific reason, in my opinion (unless I misread, this seems to be the case you're stating?)
Using both MVC and WebAPI together in a ASP.NET Web application is quite common. Whilst you can provide HTML through WebAPI and you can provide JSON through MVC it's much cleaner to use the best technology for each.
WebAPI in particular lets you define an API once and then generates JSON, XML, ... for you based on the request.
I've a web site developed using MVC 4 ASP.net application. I'm new to .net platform & I want to add web service which would return me operating system name of users device based on certain input.
Assuming I've logic to capture OS information using inputted data, how do I go forward in building this web service?
Do I need to have a complete separate solution file which will have a web service or in existing MVC 4 asp.net application itself, should I create a new project which would be of type "WCF Service Application"? Again I don't know much about WCF service either, if I use it, how would the URL be accessible, etc?
Can anyone give me some insights?
Note: I've also a separate REST web service which is a completely separate solution with separate projects but deployed on same IIS.
Thanks in Advance!
You don't need to create a WebAPI project just for what you described (i'm assuming one or a few end points).
Simply use MVC controllers that return JSON for example, this way you deal with a single framework.
Reasons to move to Web API is if you need support for CORS, need content negotiation for results etc. From what you are describing it's completely fine to stay with MVC.
Can I have an ASP.MVC 3 application running in my site root (a simple CMS to provide MOST site content), and have it co-exist with additional ASP.Net apps (2 Web Forms apps and 1 MVC app) running in subfolders to provide more specialized functionality?
Example:
www.mycompany.com
/ // ASP.MVC 3 App goes here to handle 90% of our page content.
/store/ // Older web forms app to handle our online store.
/survey/ // Older web forms app to provide survey forms.
/locations/ // An ASP.MVC 3 app to render a map with site locations.
I wouldn't mind integrating the 'locations' MVC app with the CMS if necessary, but if they can be separate, it would simplify long term maintenance. Does the root application need to know about the others? (including the other projects as subprojects into the main MVC project in VS.2010?)
As for the 'store' and 'survey' Web Forms apps. They are running .Net 3.5, but we could recompile them to 4.0 if needed. Do the 'store' 'survey' and 'locations' folders need to be virtual folders mapped in with IIS?
Hopefully this example is simplified enough, to find out if it is possible (and how) to integrate applications together with ASP.MVC 3 running in the site root. I'm in a situation where the separate apps must share a domain and pretend to be 1 cohesive site. (They will all share the same HTML template)
Just mark those other applications as Applications in IIS and that will do.
Not directly -- you'll be fighting nasty IIS battles all week methinks. You might be able to get there eventually but it won't be pretty. There are two potential approaches here:
a) Put the entire thing behind a reverse proxy that passes traffic to the appropriate server (or virtual server). Downside is you might have to do a little tom-foolery to convince IIS that your store is running at http://www.example.com/store instead of http://localhost:666/store but it is doable.
b) Try and incorporate the old webforms apps into your MVC cms app. Really depends on lots of specifics but could be as easy as setting the route to be ignored and tweaking config as appropriate.