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
Related
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.
I am a web guy and I was just hired by a company that does only desktop apps (WCF/WPF) to help them start moving to web apps, using asp mvc.
Their current architecture uses 3 different servers, UI on one, service on one and DB on one, apparently to keep the UI and DB very separate.
So with moving to web apps, I am wondering how mimic that architecture. They are mostly internal apps, so I really dont see a reason to involve 3 different servers. If we do Web API apps with MVC front end, can the API and front end be on separate servers? I have never done web api stuff, so not sure of the structure.
I am used to a repoitory pattern (UI > ViewModel > Controller > Repository > ORM/EF > DB ) with a repository between the controller and and DB. How would web api be better?
I am facing one problem.
I have 1 Presentation Layer Project using ASP.NET MVC. There is another project for Database interaction for MVC Web API.
Question: Do I need two domains ? One for ASP.NET MVC Project and another for MVC Web API project ?
Two domains? No. However, given that you have two projects you will need two separate deployment locations. That means they'll either need to live at different subdomains (i.e. www.domain.com and api.domain.com) or under different virtual directories of the same domain/subdomain (i.e. domain.com/web and domain.com/api. You could put one of them in the root of the domain (i.e. domain.com for the MVC site and then domain.com/api for the Web Api, but you need to be careful at the point, as the Web.config for your MVC site will apply to any virtual directories under it, i.e. your Web Api.
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.