In a recent project, I built my own MVC framework in PHP. One of the things I implemented was a routing system. I used Apache's mod_rewrite to send all requests to index.php, and then parsed the URI to extract information and route the request.
I'm dabbling in ASP.NET now, and I'm wondering if/how I might perform something similar. Is there a way to route all requests (similar to the way WordPress does it) to one page where central route processing is performed? I'm aware of the MVC framework for ASP.NET, but I'd like to take a stab at this myself as I'm tinkering around and learning.
EDIT:
BTW, my hosting provider runs IIS 6
This is going to be a long answer, because I want to make sure you are fully aware of all the ways you can accomplish what you want to do.
The routing engine that powers the ASP.NET MVC Framework will work with the traditional ASP.NET Framework. You can take advantage of using the RouteTable and assigning routes, just like you would in an ASP.NET MVC application. You just don't get the MVC portion in traditional ASP.NET sites. That was a huge enhancement for the ASP.NET Framework and it was great to see them reuse that code and make it work in both frameworks. If you want to learn more about this, check out ScottGu's post and scroll down to URL Routing Improvements. Also here is a reference on how to use the System.Web.Routing in WebForms by Phil Haack.
Now, if you still want to write you own. You will need to learn the ASP.NET HTTP pipeline and how to implement the IHttpModule and the IHttpHandler interfaces to create your own HttpModule or HttpHandler class to handle your routing. These interfaces are the key in writing your own routing engine. To help put those interfaces in a working example, I couldn't recommend this MSDN article enough. It shows you how to with either interface and explains the differences when creating your own routing/url rewriting engine.
Now, if you find out that this might be to much for you. There are third party libraries you can use of people who already wrote a routing/url rewriting engine in .NET. Here is a question that I saw not to long ago asking "What Url rewriter do you use for ASP.Net?" right here on SO.
Related
I wish to implement REST service which will be integrated with ASP site (basically the same project).
I've tried to provide my custom VirtualPathProvider (VPP) and it works, but to a certain degree. First, the content-type of the response is always application/octet-stream. Second, only GET requests are piped through the VPP. I've seen people playing around with HttpApplication to solve these problems. I am not sure if I wish to follow the path of hacking the ASP as it might take a lot of time, and in the end it might be simply impossible to accomplish the task.
Is there a way to do it, or I should create a separate page for MVC, and talk with it via some inter-process communication. This way MVC will be handle the REST requests and call my code in response. And vice versa - ASP will be able to send REST requests to remote servers.
If there are any other, cleaner, safer & easier, ways of linking MVC with vanilla ASP, then feel free to post them in comments/answers.
VirtualPathProvider is meant to be a way to virtualize the filesystem for internal ASP.NET operations (e.g. storing *.aspx and *.master files in a database), it is only coincidental that it works for user-provided URIs and requests.
Your best bet is just to use ASP.NET MVC, which is now integrated with ASP.NET (since 4.x) or as an easily redistributable component in .NET 3.x. ASP.NET MVC does play nice with WinForms in the same application, so don't reinvent the wheel.
However, if you are insistent, the only real option is to do it all from within a custom IHttpHandler that chooses to handle incoming requests or not (as you won't have ASP.NET URL Routing because you're not using ASP.NET MVC).
Or is Rails by itself just good for developing APIs?
It seems that ASP.NET Web API project types have some history intertwined with WCF (as is detailed in this post for example), so maybe it's not applicable to Rails.
UPDATE
To clarify, Microsoft has the ASP.NET MVC framework. Recently, they came out with a framework called ASP.NET Web API. ASP.NET Web API seems to have similarities to ASP.NET MVC, but is specialized and trimmed down for RESTful web services. Is there an equivalent in the Ruby/Rails space?
So, the answer is Yes to both questions. Rails does have an equivalent and its Rails.
ASP.NET Web API looks like at it's heart is just a RESTful router with type negotiation. I could be totally off base here, but from the tutorials I saw that's what it looked like to me.
So yes, from what I can tell, Rails supports most of the things that the Web API was created for. In fact in Rails most of this stuff is forced onto you until you become informed enough to be able to change it (assuming by that point you know better than to actually do that).
But, as far as Web API functionality. That really comes from the ability to support HTTP verbs (GET, POST, PUT, DELETE) which Rails does.
But a source of confusion might be that in Rails the RESTful API is actually the application itself. Meaning you don't need to implement any other libraries, it's just built that way.
Here's a quick example of that I mean
When you hit /users/1 you will get the data associated with that user depending on the format you requested. So if you request JSON the controller returns JSON, HTML you get HTML, XML you get XML, etc. (As long as said format is implemented for that resource)
A good overview of what I'm talking about are in these two sections:
Rails Guides::Controller: Rendering xml and json data
Rails Guides::Routing: Resources on the Web
So you could build a website, API, or both in a Rails app and they would all start the same way.
But from my limited knowledge on the matter, I would say a ASP.NET MVC with ASP.NET Web API program is actually a lot more like a Rails Program than the regular ASP.NET MVC programs that came before them.
Or it's all just a clever ploy to get as many Capital Letters in a title as humanly possible.
Take a look at grape. It is a pure "Rest" HTTP API framework in ruby.
WSO2 looks like a generic web services framework (as opposed to MVC like Rails) I can't vouch for it but it seems to be more a service framework in the style of WCF Web API (service in the generic sense, not just SOAP).
It's difficult to know what you mean by "APIs"... Rails and ASP are used for developing web sites, and WCF is essentially a web service platform. ASP and WCF have little in common, it's just normal for ASP applications to consume WCF services because they all run on the same stack and platform.
I suppose Rails on the Microsoft side would be a combination of ASP.NET MVC, Linq2SQL or EntityFramework and some WCF.
Ok, this isn't a direct answer to your question, however there seems to be some confusion... Microsoft's ASP.NET Web API is specifically a product offering with ASP.NET MVC 4+. It is a RESTful framework. How does it compare to RoR? I don't know having never tried to install RoR on Windows. As with anything else, experiences vary... Requirements vary. Also try to think ourside the language, construct, context, and framework. Is it better for developing API's? If you're using Linux/Unix, the answer is probably a yes. If you're on a Windows server, the question is a bit trickier.
Finally,
Writing in the ASP.NET Web API will have 0% to do with WCF. Perhaps it is implemented as such under the covers, but the ASP.NET Web API is (from what I've seen and done with it) strictly an HTTP bound API, not TCP/Binary/Piped/etc... like WCF. If you're ask
Yes. It's called Grails. It uses spring. There are tons of plugins available for it and it make creating webapps a breeze. Read more about it here.
I'm just wondering, if you are creating a new ASP.NET web forms app in ASP.NET 3.5, which would you recommend for URL rewriting? UrlRewriter.NET or ASP.NET MVC Routing. I've used UrlRewriter.NET before and was pretty happy with it.
Opinions anyone?
Routing is vastly superior IMHO. Rather than faking it (rewriting urls to keep the SEO types happy) you are making it (making real urls to keep the SEO types happy). The other huge advantage is that routing is reversable--you can easily get the URL from the parameters, which comes in very handy.
No, they do vastly different things. The url rewriting takes an incoming url and rewrites it before passing the request off to ASP.NET (or IIS) to handle. Url routing takes a url in ASP.NET and maps a handler using parameters found within the Url. The Url itself is never changed.
Use UrlRewriter.NET - it was built for web forms and you already have experience with it and like it. ASP.NET MVC routing is designed to work within the MVC pattern.
If you are using IIS7, go with the URL Rewrite Module.
I used it for one of my sites, and it worked perfectly.
Why not just go with Asp.Net MVC and ditch the webform methodology altogether? I realize that the framework isn't for everybody, especially for pre-existing projects, but if you are starting to develop a new app and are shopping for a routing mechanism, why not go for the framework that is built upon the notion?
Asp.Net MVC is a vastly superior framework over WebForms, it just requires a bit more upfront work and has a learning curve. At the end of the day though, you'll generally end up with an application that is much easier to expand and maintain.
ASP.NET 4.0 web forms (I believe that it was introduced in 3.5 SP1) has routing build in natively. It has the benefit over rewriting modules that it is build in natively in the ASP.NET frameworks, and therefore does not need hacks to work correctly.
So you shouldn't go for MVC just because of the routing.
I will apprecaite your help in this topic.
I need to build a site with friendly urls using url rewriting in order to improve SEO positioning.
I've been searching torought web and finally pointing to this two main options :
asp .NET with isapi extension
asp .NET mvc
however, I got no experience on both items so I need you to help me to kwow further about this two technologies and to take the right decision for my needs.
Thanks
There are much bigger concerns than just URL setup when making this choice. You're talking about two completely different architectures for building your web pages.
You should make the decision on how you want to build your application, what skillsets you have available in your developers, etc. Both approaches will be able to handle the URLs that you need to generate for SEO considerations.
For public facing websites, I would personally choose ASP.Net MVC, because I find the development cycle shorter, more productive, more flexible and more maintainable than an ASP.Net webforms application.
Assuming you have a host/server that can run ASP.NET MVC (i.e. one that has the .NET Framework 3.5 Service Pack 1 installed on it), you can use the Routing Engine (System.Web.Routing) from ASP.NET MVC in a web forms environment, Phil Haack has a good updated walkthough at "Using Routing With WebForms".
There's also "How to: Use Routing with Web Forms" on MSDN.
Unlike an ISAPI filter, this enables you to use the routing engine to generate your internal links as well as responding to well formed links from outside.
I agree with womp. But there is one advantage i see in Asp.Net webforms that Asp.Net Mvc doesn't have: Rich Client Iteraction controls. Everything in Mvc in View layer is simple and functionality need to be build from scratch.
alexserver - at the same time of course, the fit between mvc and jquery is an overwhelming reason to abandon the rich clinet controls. that way, you can literally get your designer and/or a jquery UI expert to work on the view portions in isolation whilst you craft the model and controllers.
I know what MVC is and I work in webforms but I don't know how MVC will be that much different. I guess the code behind model will be different. So will it be like webforms minus the code behind and instead having it in a controller?
I see there are other related posts but I don't they address this.
For starters, MVC does not use the <asp:control> controls, in preference for good old standard <input>'s and the like. Thus, you don't attach "events" to a control that get executed in a code-behind like you would in ASP. It relies on the standard http POST to do that.
It does not use the viewstate object.
It allows for more intelligent url mapping, though now that the Routing namespace has been spun off, I wonder if it can be used for WebForms?
It is much easier to automate testing of web parts.
It allows for much easier separation of UI logic from the "backend" components.
The image says it all.
Update: Adding the original link for completeness.
http://forums.asp.net/t/1528396.aspx?MVC+vs+Web+Forms
The video tutorials here help describe the differences.
There is so much that can be said about your question.
MVC allows for clean separation of concerns, testability, and test driven development (TDD). It supports clean RESTful URLs and is very extensible... meaning you could swap out of the viewing engine, the routing mechanism, and many other things that you might not like out of the box.
For additional information I would suggest reading Dino Esposito's blog post entitled An Architectural View of the ASP.NET MVC Framework. Inside this post he compares many differences between the classic code behind approach with MVC.
Asp.Net Web Forms:
Asp.Net Web Form follows a traditional event driven development
model.
Asp.Net Web Form has server controls.
Asp.Net MVC model:
Asp.Net MVC is a lightweight and follow MVC (Model, View, and
Controller) pattern based development model.Asp.Net MVC does not
support view state.
See more..