Database driven asp.net MVC application - asp.net-mvc

I have a CRUD application written in Classic ASP (not .net) which transfers (routes) page requests to relevant servers using a loadbalancer DLL.
It works like this:
Someone requests for www.mywebsite.com/products
There is an index.asp under folder products that redirects the request to either:
http://www1.mywebsite.com/products
or
http://www2.mywebsite.com/products
based on a loadbalancer logic.
Another scenario:
Someone requests for www.mywebsite.com/products/details
There is a index.asp under the sub folder details within the products folder that redirects the request to either:
http://www1.mywebsite.com/products/details
or
http://www2.mywebsite.com/products/details
based on loadbalancer logic
The main issue with application is whenever I include a new page, I need to create a folder and index.asp page to redirect the page.
We have a CMS database which contains the details of all pages. So I want to create an MVC application to replace the existing Classic ASP application.
But I didn't find any database driven MVC applications and I'm bit confused by routing. Do I need to create a separate route for each main folder I have or should I create a generic route for all pages.
Any help would be appreciated.

You don't have to migrate to ASP.NET MVC just for the URL rewriting.
IIS 7 does have an integrated URL rewrite module and ASP.NET 4 includes routing as well.
IIS URL Rewriting and ASP.NET Routing
URL Rewriting in ASP.NET
Anyhow, if you search e.g. on Codeplex for ASP.NET MVC projects, you'll find a lot of them which are database driven.
You don't need to create individual routes for each seperate item. Think about the concept of querystrings (?id=15&day=monday). URL rewriting is pretty much the same.
Update
I've overseen that your talking about classic ASP.
The build in URL rewrite module in IIS 7 works also fine with classic ASP. If you are having an older IIS version you need a 3rd party ISAPI rewrite module.
Anyhow, switch it to ASP.NET MVC ;)

MVC would lend itself very well to sorting your routing problem. So would ASP.NET 4.
However, the problem you have is that you don't know enough to ask a precise question. Hence your confusion with routing in MVC.
I would therefore suggest reading the nerddinners tutorial. You can get a PDF download for free. To go a step further, read Stephen Sandersons book on MVC 2 (or MVC3 in a couple of months).
If you follow the nerddinners tutorial and Stephen Sanderson's tutorial, that will give you a better idea of how it works.
In short, this is how MVC works:
In MVC, you forget about files and folders.
Instead, you have Controllers and actions. The routes map the requests to the right controller and action.
The code in the actions then decide which View to stuff full of data (from a database or wherever, it doesn't matter). The Views are just templates that are told what to do and what data to display.
The Controllers ask the Model for the data that they want.
Ie, the data access is all done in the Model, neatly separated from the User Interface.
M: Model
V: Views
C: Controller
The above is probably meaningless to you. It is a VERY different mindset to ASP classic.
If you are coming from old ASP, you will have a long hike, but it can be done. I came from Access. Anyway, read the books, follow the tutorial and see if it is for you.
When you are ready, we will still be here to help with more precise questions.

Asp.net MVC routing in your migrated application
Based on requests you've shown here you can sort everything up with just default route:
{controller}/{action}/{id}
In your case you'd have a ProductsController with all the actions you need.
Load balancing application
But having an Asp.net MVC application is just one part. This application will run on both load balanced servers. All redirecting should be done before they hit the MVC application.
If you intend to continue using the same loadbalancer DLL you could create a different Asp.net MVC application with only one route definition:
{*path}
and a single controller and action that does it all:
public Load: Controller
{
public ActionResult Balance(path)
{
// decide for web server and attach path to subdomain
}
}
This should do the trick just fine as long as the overhead of this action is very small. Otherwise your load balancing logic will become the bottleneck of your application since all requests go through this load balancer (it does that now as well so bare in mind this is no different now; never mind the authentication process on different subdomains you may be using).
Load balancing alternative
You should consider using the web farm balancing capabilities on the IIS 7 that will run your application on several web servers (because that's what your load balancing does in the first place). Search the web for web farm information. You can start with this:
http://www.iis.net/download/webfarmframework

Related

Web Services in ASP.NET MVC 4 Application

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.

Why does every new asp.net mvc 4 project template base on WebApi Controller

When I create a new ASP.NET MVC 4.0 project e.g. Single Page App or Mobile etc... they all have Controller classes inheriting from ApiController.
I do not need to expose a web service to someone else. I just want to run a public website with a private webapplication if logged in. I do not want ApiController but I want a Single Page App.
Why have they done it that way?
WebApi does not necessarily imply that you are creating a web service for someone else. Instead, when you are developing a single page app, you would use the WebApi controllers to deal with getting/posting data via ajax.
There is nothing stopping you from using regular controllers, but the WebApi is well suited for SPA. See any of the online tutorials where this technique is used.
It sounds like you want to create an Mvc4 Web Application using the Internet Application project template. This template uses forms authentication and creates controllers that inherit from System.Web.Mvc.Controller. If you are using Visual Studio 2012 then this template is installed (along with a handful of others including the Api Web template).
Right click on your controllers folder -> Add -> Controller and then choose an MVC controller from the template drop down. You don't have to use an API Controller.
If you think of what a SPA is, it's essentially an HTML page that uses JavaScript to get data from a WebAPI or some other web service. Like Bort said, web API calls are very well suited for SPA.
Personally, for a single page app, before they added the SPA template in Update 1 I'd just create a static .html page and make RESTful calls into my WebAPI controllers.

WCF REST Web API and MVC on same server and port

I'm looking at putting together a REST based system which still has a standard browser style access. My desire is to have both of these on the same machine, but what are my options?
Use IIS to host both the web-site and the REST service (different URIs, e.g. http://mysite.com/ and http://mysite.com/api
Use IIS and some magic I don't yet know to have two domains mapped to the same machine but different services (e.g. http://www.mysite.com and http://api.mysite.com
Combine the two technologies into a single service (that perhaps uses routing tables to direct the requests to MVC or WCF where appropriate).
My preference would be the third option, this would allow me to have a single code-base and single repository accessing. The WCF page on codeplex mentions in its release notes, "not tested with MVC3" - is this suggesting that this is a possible approach?
I'm not keen on using MVC for the REST implementation as it is intended that the majority of interaction with my site goes via API, so I want that as the focus.
I've ported the contact manager to use MVC 3. It definiately works though we've not done exhaustive testing. The one thing in general to cognizant of with regards to web api is that both MVC Routes and Service Route are greedy. If your default route is first then MVC will try to grab your HTTP Service requests. One thing you will want to do is put your Service Route first before your MVC routes. If you run into additional issues, you may need to use custom routing constraints.
In http://webapicontrib.codeplex.com there is a sample that works with MVC 3. It is in the Samples/experimental folder. However, it was built with a custom version of WCF Web API. I don't believe it needs to be though. I've been meaning to get the author of the sample to switch it over.

Can ASP.MVC 3 run in a site root and allow other ASP.Net apps to run in subfolders?

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.

Classic ASP integrated with ASP.NET MVC

I have a classic asp project and a teammate created a new functionality, but it's in asp.net mvc. I also know how to work with mvc, but I never used classic asp and mvc together.
For example, is it possible, in this classic asp project, to have a link that will redirect to a mvc page on the same project?
Thanks!!
Yes, you can have a link point to any other page you'd like regardless of technology. Likewise for a redirect. To redirect in classic ASP, use Response.Redirect
Absolutely, the pages (and that term is used lightly in the MVC side of things) can link between each other without any problems. Now, any built-in authentication or session management or anything like that will be considerably more challenging, but if all the sites need to do is link to each other then they can do this like any other two websites. The ASP pages can host manually-crafted (vs. HtmlHelper-crafted) links to the MVC actions, and can host forms that post values to the MVC actions (provided the field names line up properly).
There's nothing inherently special about the MVC actions. They're just handling HTTP GET/POST requests like anything else.

Resources