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).
Related
I want to build a Single Page Application using AngularJS as an client side framework but I struggle to understand if I can use the ASP.NET as my server side framework?
I know that AngularJS is an MVC framework and when I'm trying to decide wich server side framework to chose all I hear or read is MVC, MVC,...,MVC.
I know, this an subjective question, but still, can any one tell me if I need to learn ASP.NET MVC or I can still reach the desired result using the ASP.NET framework?
You can use whatever technology you want.
Basically to be able to communicate with angular you need something that listen for http requests (an http server so), parse them and that can send/read json (with maybe some extra libraries). The static pages can just be deserves by an apache in front.
You could do that in C parsing the whole thing yourself, but for performance, maintenability, speed of development and a bunch of other reasons, it's better to use an appropriate framework.
If your application is not big-scaled, specially in the backend part just search for a c# rest framework that handle thing that url mapping and json.
I am currently starting a massive web app project, and one of the requirements is that down the line I may be required to allow an iOS and Android app to interface with my application, I figured the best solution was to create a RESTful API and have the web application interface with it. However, my coworker who does front end development is unfamiliar with using a javascript framework such as backbone.js (more of a library I know), ember.js or angular.js. Since we're using asp.net I figured that the I could handle authentication and routing using asp.net MVC, delivering seperate views depending on the route, and he can handle the data manipulation only, However, I can't seem to figure out how to seperate routing from the javascript framework, I've looked into ember.js and backbone and both of them seem to require routing to be handled on their end for it to really work.
Does anyone have any idea how to implement data manipulation without the need for routing?
What you are describing is generally called API oriented architecture, meaning you have a RESTful service on a back-end and rich client-side application on front end.
The point is, it basically does not matter what technology you pick up on server. It could be anything: ASP.NET MVC, Web API, Express.js or Django. As soon as it's really RESTful and pure. By purity I mean, it deals only with data, no serving of HTML or something.
Server just specify the interface you work with data,
GET /invoices // get all invoices
GET /invoices/:id // get invoice by id
POST /invoices // post new invoice
If you confident with .NET, WebAPI is probably good choice. Typically you would prefer JSON output, WebAPI could handle content negotiation for you.
Now, the client job is to consume the API data and dynamically create HTML in browser. A lot of options now: Backbone.js, Angular.js etc.
Please be aware: client side routing and server side routing are completely different things.
Server side routing: routes particular HTTP request to particular controllers action (or any function).
Client side routing: detects the URL change and triggers corresponding JavaScript function to handle change. Client side routing is vital for SPA (single page applications). You can find a bit more information on SPA on that blog post.
Have a look at KnockoutJS, which would allow you to use ASP.NET MVC for routing or another JavaScript library like sammy.js (just for routing) or Durandal (for routing and navigation).
Note: Durandal version 1 used sammy.js internally, but version 2 has a custom routing engine and no longer uses sammy.js.
I have just experimented my first ajax enabled WCF service in a sample asp.net webform application... If i have 10-15 pages in my webapplication which involves add,edit,view and delete operations, is it possible to make them ajax post and get without using .cs(codebehind) of all pages...
What are the pros and cons when choosing ajax enabled WCF service in an asp.net webform application?
At first, if you want to implement the server side of jQuery Ajax calls, you can do this with either ASMX or WCF services. You can find a short comparison between these two here. WCF is more modern technology and will be my preferred choice for new projects. It can provide you with the following:
Help you program against an interface
It will serialize/deserialize objects to JSON for you. No need for JSON libraries
Provides client methods that you can use (via the ScriptManager). It is also easy to use jQuery if you prefer
As an disadvantage I would say that it will take you some time to learn the technology. I found that proper configuration of web.config was a little tricky.
I usually have a single svc service that serves all Ajax requests. You can implement as many methods as you want in a single service. The services are called from different pages.
I've just been tasked with building a web application using ASP (.net) and am looking for some advice on where to start. In a nutshell the application needs to be able to.
Handle user verification / authentication
Handle sessions
Do SOAP messaging
The application is intended to act as a front end for system functions that are accessible via web service calls.
I intend to do a lot of work on the client side using JavaScript and am thinking of using ASP solely as the framework for the 3 items I listed above.
Appreciate any suggestions you may have.
Use Visual Studio 2008 if you can. Its support for Ajax client libraries and javascript intellisense is very good. (Check out the jQuery add in)
ASP.NET has built in Login controls (and the membership services mentioned by ChrisE), and also has Forms Authentication. Try to leverage these existing components and avoid using session to store user specific objects/data.
---session rant
Its sometimes unavoidable, but you should avoid it whenever you can. It incurs a burden on the webserver for each user, and that leads to some very difficult scaling problems. The FormsAuthentication Ticket has a value property that you can store about 4K worth of user data in - try to use that instead.
---End session rant
Try to use a MVC approach (not necessarily an ASP.NET MVC), but at least one that seperates your presentation / view layer from the data / model layer.
Create a default theme and use it. Most sites will need to have multiple themes later, and refactoring that will be a PIA.
If you need SOAP to interact with Non-.NET services then by all means use it. If you are only connecting to .NET services then look into WCF clients and services. They will give you more flexibility.
If you are doing the client work in javascript, then dont use the update panel. It adds lots of overhead.
Get FireFox + FireBug + YSlow, and IE8 (yeah its beta still). They will help you when dealing with the client end of debugging / styling.
Take a look at the rules for website performance, but take these with a grain of salt. They are intended for very large sites, and some of the items may not be applicable (CDN, DNS lookups, Redirects).
WCF for Soap -- I would also suggest picking this up:
alt ASP.NET 3.5 http://ecx.images-amazon.com/images/I/518N8vYWf1L._SL500_AA240_.jpg
This book is in tutorial form -- and Jesse Liberty is a great teacher (as are his co-authors).
ASP.NET provides out of the box authentication/authorization through the SqlMembershipProvider and SqlRoleProvider classes, or you can use the ADMembershipProvider along with a custom RoleProvider to authenticate and authorize against an Active Directory setup.
Session handling is readily provided by ASP.NET as well, through an in-process server, an external StateServer service, or through a connection to SQL Server (and of course, you can provide a custom Session service if you need something different).
As Lou Franco mentioned, WCF provides the framework for the SOAP calls, and will blend in with your ASP.NET application quite handily.
If you are using ASP.NET Web Forms then for handling user authentication/verification I'd recommend ASP.NET Membership services http://msdn.microsoft.com/en-us/library/yh26yfzy.aspx because it does some of the heavy lifting for you and also helps you from making any elementary security mistakes.
This is not directly related to your requirements, but I'd suggest you study the differences between Web Site and Web Application. The sooner the better. Everything will go smoother if you understand how the project is managed.
You can start here: http://www.codersbarn.com/post/2008/06/ASPNET-Web-Site-versus-Web-Application-Project.aspx
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.