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.
Related
I've explored the ASP.net web API framework and MVC 4. I understand the point of using web API that only return data then in client side we use javascript, ajax to handle all actions via HTTP verbs. On the other hand, MVC controller can return data and view we can handle event via [HttpPost] in controller.
I saw some people they make 2 projects in a solution: one is Web API in MVC 4 and the other is MVC 4 Internet Application. Is it a good idea? I didnt see the relation between two kind of projects. Can anyone explain me the how two project can communicate with each other, and what is the advantage and disadvantage of that way?
Note: in this solution he/she still uses Httppost to handle event and use MVC controller return view with Model binding.
Well I guess this is going to be a pragmatic conversation...
For starters, it seems like the Asp.net WebApi and Asp.net MVC are going to be aligned in Asp.Net V-Next, so there is going to be One base controller class that will return what ever datatype you wish (ActionResult, Json etc).
And from the recent years experience I think the trend is to have a WebApi that exposes data and a portal(client) that is just a JS web application with no C# code that just calls the Api from the browser and does what it needs to do.
So that way we basically save one hup to the server(the MVC server) and we can directly call the API from the browser.
However some people would still argue about load balancing, scaling, caching etc that you could have if you keep the MVC tier there but still all those things could be done in the WebApi and JS application too...
So long story short, I think if you want to move with the trend I think you should go with a RESTful API and have your client to call it from the browser directly with JavaScript...
I have been using asp.net MVC for around 1.5 years, am enjoying its capabilities, and have deployed many successful web applications, but I'm currently reading about the asp.net Web API technology. And, I find the following:
I can implement any functionality that I used to implement using MVC; using the new Web API and in a more lightweight approach.
It is easier to develop web services using the Web API comparing the asp.net MVC.
So, will the asp.net Web API take over asp.net MVC in the future, or each technology will have its own area to grow in, or should we consider using both of them in the same web application?
Besides the #jmoerdyk's answer, I would like to point something out:
The key is to understand the goal of each technology:
Web API.
This will be the new API for creating web services, this is an alternative to traditional XML services and WCF services, so it's worth pointing out first the main difference between WEB API and the rest of the Web service frameworks.
The primary difference between Web API and WCF/ASMX services is that it's not based on SOAP it's based on HTTP Therefore you can take advantage of all the HTTP features like:
It contains message headers that are very meaningful and descriptive - headers that suggest the content type of the message’s body, headers that explain how to cache information, how to secure it etc.
use of verbs to define the actions (POST, PUT, DELETE..)
it contains a body that can be used to send any kind of content
It uses URIs for identifying both information paths (resources) and actions
That was the main goal of the Web APIs, known back then as the WCF Web APIs: to stop looking at HTTP through the eyes of WCF - as just a transport protocol to pass requests. Rather, it allows us to look at it as the real application-level protocol it is – a rich, interoperable, resource-oriented protocol. The purpose of the Web APIs was to properly use URIs, HTTP headers, and body to create HTTP services for the web, and for everyone else that wished to embrace HTTP as its protocol and lifelong friend.
Take a look to this article for more information: http://www.codeproject.com/Articles/341414/WCF-or-ASP-NET-Web-APIs-My-two-cents-on-the-subjec
So basically the Web API could actually be compared against WCF or XML Services
If you are wondering what's going to happen with WCF?
So the fact was we had too many options and therefore too much confusion. What were we to do? We merge teams! (Kind of reminds us of the time of LINQ-to-SQL and Entity Framework, WCF and Ado.Net Data Services and other such examples). So the WCF team and the ASP.NET team joined forces and created a new framework focused on the world of REST/Hypermedia/HTTP services for the web world and thus came out the ASP.NET Web APIs.
MVC
Now that you know what's the goal of the Web API, then it should be easier to say why MVC contains additional functionality to render views primarily.
Your concern is based on the fact that WEB API is actually based on MVC, but their goals are different
On the other hand, the ASP.NET MVC infrastructure with its elegant handling of HTTP requests and responses, and its support of easy-to-create controllers seemed like the proper way to go for creating this new type of services
No, they don't really do the same thing.
Web API is really only for generating JSON, XML or other text based responses for implementing REST based APIs. MVC can do that as well, but the new Web API appears to make it easier, particularly with the automatic content type negotiation.
What MVC does that Web API is not intended for is generating full or partial HTML pages with Views and such.
So each one has their own purpose in the ASP.Net framework and not likely to surpass the other.
WebAPI and MVC are two different things, but they both work in the same framework. WebAPI is used for restful services. MVC is used for web pages.
You can create restful services in MVC, with a lot more work than in WebAPI. The reverse is not true. You can't create Web pages in WebAPI. Therefore, your question is fundamentally confused.
They are going to be merged in new versions, technically both works similar, but API don't have views attached so delivers better performance
I recently inherited a project from a developer that is no longer with us. I'm fairly new to web development and the limited service work I've done involved WCF (.NET 4).
The project includes a series of service calls where an .aspx page is called (often with parameters). The markup of the is something like this...
<%# Page Language="C#" %>
<%
// <!-- Get tasks -->
// return as JSON string
Response.Write(DataAccess.DataManager.DoStuff());
%>
All the heavy lifting and processing is done in the DAL. The DAL returns an int or, more often, a JSON string. The .aspx page returns the results to the caller.
This is an internal application so I'm not too concerned about the security of this technique. We are using Windows authorization (ADS). The caller will often, but not for all calls, send a key with the request and that key is checked for authorization.
Is this an acceptable way to create a web service? What is the technique called? I'd like to know more about the guidelines for modifying / creating new services this way as this project will require maintenance for some time.
Unless the page needs page specific components it is recommended that you use an HTTP Handler for tasks such as this. They will be lighter and faster.
It is a way to implement a web service. Looks rather old fashioned to me.
These days one would use WCF for web services - see here and for RESTful WCF, here.
In a sense "anything that works" can count as a web service, since the consumer shouldn't have any reason to care about how the service is implemented, as long as it fulfills the contract.
That said, this looks like a hack devised by someone who was used to using ASPX pages, and didn't have the time or gumption to learn to use frameworks that were designed for this sort of thing. I'd suggest migrating it to WCF, which provides a lot more flexiblity for web services.
(Windows Communication Foundation) WCF is what you want to be looking at just now.
There are basically two formats SOAP and RESTful services.
RESTful are being more and more common and are very easy to consume. They are also easy to develop for in .NET 4.
http://blogs.msdn.com/b/endpoint/archive/2010/01/06/introducing-wcf-webhttp-services-in-net-4.aspx is a great tutorial with samples that takes you from "File > New..." to having a published RESTful service in .NET 4.
I have an existing Asp.Net MVC Website and I would also like to provide a Web Service from the same domain.
What is the best way to approach creating a web service in this scenerio?
Do I add to this project or...?
You should be able to add an WebService file directly to the MVC project.
Right click on solution and select add new item, then select the web category and att the bottom of the list there should be Web Service.
Just remember to check that the routes does not eat up the call to the webservice.
That way the webservice can get access to the same model classes as the MVC application.
You can add a web service to the project just as you do in regular ASP.NET web apps, however, MVC basically IS a web service. You could create a controller that handles all the requests that you want your web service to handle.
With the advent of MVC it is quite common to do applications that only ever load a view once, then use AJAX and client scripting almost the entire rest of the life of the application. Your AJAX calls just hit up action methods for their goods and then use the deliciousness that is JSON to parse the data and utilize it.
In my opinion designing a web service as a controller instead of using [WebMethods] is far simpler and a lot more fun!
First, the question is "what do we mean by web service?" This can mean anything from a MVC page that responds using XML, JSON or some other agreed upon format to full blown SOAP and WS-* encumbered nightmares.
Anyhow, perhaps the best place to start is the WCF restful services -- these play very nicely with MVC, including routing.
The cool kids are using openrasta.
I am prototyping a AJAX based web application running up against ASP.NET, where I need to have general authorization to different parts of the site, and also have to make sure that various web methods/web services can't be called by unauthorized users (from a rouge html page for example).
Is there anything I need to be aware of, or do things just work as if I was doing regular ASP.NET?
A set of best practices or things to look out for would be fantastic.
A side question, what do I gain by using WCF compared to ASMX?
Regards, Egil.
It works basically the same way as with regular ASP.NET and ASMX/WCF. The big difference is that you'll need to use the Membership API from the client-side (whioh is fully supported by ASP.NET AJAX).
Check out these resources:
endpoint.tv - Securing RESTful services with ASP.NET Membership
How Do I: Use the ASP.NET AJAX Profile Services?