I need some advice here.
I need to make a webservice, that can make a simple query into my database, from any C# project.
Basically, I'm looking up an itemnumber, and returning the itemname.
It looks like WCF Data Services are really cool, but I'm not really sure it makes sense in my case. From what I have read, they are good for browsing datasets, where I just want to return 1 string.
But, at the same time, I don't want to use obsolete services, or services that are dying. From what I can tell, the good old ASP.NET Webservice (ashx) seems to fall into that category.
So, my question is, what type of webservice should I use?
You could use a standard WCF service (not WCF Data Services).
Related
I'm wondering which is better approach from performance point of view, is it better to use one web-service method to load data by passing Database Table name and keys or is it better to use separate method for each database table! knowing that i'm using .net asmx through ajax requests.
it's obvious that one method is better from OO perspective since it have one function type 'data loading' but what about performance? does IIS affected by that or not? also is it better to make multi web-services 'asmx files' or just one!
I really dont think that creating separate methods for handling data fetch different tables is necessary. The performance gain\loss that u r likely to experience by passing an additional table name param to your webservice call would be too small to even consider unless your table names are really huge, which i dont think is the case.
The only reason i would even consider doing some thing like this is if i have nothing else to do in terms of performance improvement or if being forced to do it ;-).
If you really want to optimize your request size try
serializing your input params using JSON (if you are not doing it already)
use a cookieless domain for your webservice
hope this helps
I don't think the service level should have any knowledge of database tables, just like you ideally don't want to see data access code in a controller action or ASPX's code behind.
Personally, I prefer to organize my services to match my domain model.
If I have Customer, Order, and Item classes, for example, I would have corresponding Customer.asmx, Order.asmx, and Item.asmx services to expose selected methods within those classes.
Services are typically responsible for exposing business functionality through a contract. I realize ASMX services really had not concept of "Contracts" in their broadest sense, however you think of it as a set of operations supported by the service. What is your goal here, do you want to expose tabular data as a service ?
Service technology on the Microsoft stack has come a long way from ASMX. Perhaps an obvious question, have you looked at WCF Data Services?
Links:
Exposing Your Data as a Service (WCF Data Services)
Getting Started with WCF Data Services
The intent is to create a set of web services that people can reuse. These services mostly interact with a backend DB creating, retreiving and processing data.
We want to expose services so that people can use to create data mashups and other applications.
End users are webpages that can be within our domain or outside our domain. For pages outside the domain we plan to release widgets that would be configured to retreive and display the data.
One requirement - application should be extremely scalable in terms of the number of users it can handle.
Our code base is .net and we are looking at ASPX webmethods (or ASHX), ASMX webmethods and WCF (starting to read up on WCF).
In terms of security/access I found that maintaining sessionid, memberships is doable in all three. WCF seems a bit complicated to setup. I could not immediately see the value of asmx when we can get all done just using a webmethod in aspx (with a little tweaking).
Also, assuming that with the ASP.NET MVC2 I might be able to get clean urls as well for these webmethods.
Questions
Which one will be the most effective in terms of performance and scalability?
Any reason why I should choose WCF or ASMX?
Thank you for taking the time to read through this post and apologies for the naive questions since I am new to .net.
EDIT I kind of understand that WCF is the way to go. Just to understand the evolution of the technologies it would be good if someone can throw light on why a aspx webmethod is different from an asmx when similar things (apart from discovery) can be accomplished by both. The aspx webmethods can be made to return data in other formats (plaintext, json). Also, it seems that we can build restful services using ashx. Apologies again for the naive questions.
You should use WCF for developing webservices in .Net. WCF is highly configurable with many options for security, transport protocols, serialization, extensions etc. Raw performance is also significantly higher. Also WCF is being actively developed and many new features being added in version 3.5 and 4. There are also variations like WCF data services and WCF RIA services. WCF 4.0 also has better REST and JSON support which you can directly use in ASP.Net / JQuery.
ASMX is considered deprecated technology and replaced by WCF. So if you are going to start new development which requires exposing reusable services, WCF is the way to go.
I am not necessarily disagreeing with previous answer. But, from a different perspective, WFC is tricky to configure. It requires bindings, endpoints, packet sizes, a lot of confussing parameters, etc in your configuration files, and there are many serialization/deserialization issues reported. Also WCF is a relatively new technology (therefore still exposed to bugs and patches needed).
The client-generated [Reference.cs] files might have unwanted interfaces, and each public property client class exposed in the WSDL gets generated with the same observer pattern that LINQ to SQL or Entity Framework uses ( OnChanged, OnChanging, etc) so this adds a lot of fat to the client code, as opposed to the traditional SOAP Web client way.
My recommendation, if you aren't using Remoting over TCP or if you don't need the 2-way notification mechanism for remote changes - all these are very cool features of WCF - you don't need to use it.
Okay I hear that thing all the time on internet when reading an article about MVC : "Since Asp.NET MVC is REST, it is easy to consume ... etc." I've never heard such a thing for Asp.NET Webforms and it makes me wonder what makes something REST.
As I understood, REST means Representational State Transfer in which what a user see on their browser is a state. But I don't think it means it always should be like RPC as MVC does. It could be a physical page served by the server like how it works in Asp.NET WebForms (Default.aspx) As long as it returns a state representation, it is called REST.
So if my understanding is fine, then shouldn't webforms be also REST?
Uggh, I am kinda confused....
Thanks in advance....
Edit and brief answer :
Okay folks, listen up :) this is the answer I believe which is correct :
As we know it REST should match basic principles below :
* Give every “thing” an ID
* Link things together
* Use standard methods
* Resources with multiple representations
* Communicate statelessly
So as we know it, webforms use highly postbacks, session to get idea about the previous requests and you can do postback countless times to get something like :
search.aspx and post the selected value of a dropdownmenu and there is no get, only post and postback from the server.
Well it obviously cannot be restful architectural style.
It is surprising statement. If I use session in ASP.NET MVC it will not be REST at all.
Edit:
REST is stateless. If I use session the prcessing will become stateful. Subsequent requests will be able to use state (from session) so the HTTP response will not contain whole state.
The goal of URL routing in MVC is search engine optimization, and user-friendly URLs. It is not a REST protocol in any formal sense, as it doesn't use the HTTP verbs (other than the usual GET and POST), and is not designed for data. URLs correspond to controllers and actions, not to any data schema.
MVC will also give precedence to any URL that maps directly to a file, so WebForm-type routing is still possible.
WCF does support REST, but as a data transfer protocol, not a page-mapping mechanism.
You might want to read up on REST; it really is entirely separate from ASP.NET MVC routing.
I'm currently working with web services that return objects such as a list of files e.g. File array.
I wanted to know whether its best practice to bind this type of object directly to my front end code for example a repeater/listview or whether to first parse it into my own list of "file class" e.g. customFiles[]
If the web service changes then it will break my front end code, however if I create my own CustomFile class, then i would only need to change my code in one place to fix the issue, but it just seems like a lot of extra work to create the same classes from a web service, i wanted to know what is the best practice for this type of work.
There is a delicate balancing act in properly encapsulating implementation details. Too little encapsulation is a maintenance nightmare as small changes in any area break the application. Too many layers is a different kind of maintenance headache altogether.
In this particular case I would create a small layer in your application to encapsulate the web service calls. This will ease your maintenance in both the application and the service as they will be loosely coupled.
It sounds like you have already answered your own problem. Best practice is to create your own custom class for the reasons you point out, but it is significant extra work.
If the webservice isn't likely to change then just use the existing classes, but if you need to cater for change then create your own.
Returning a class is fine as long as your client knows how to deserialize it. If it's truly a web service, where you don't have control over both ends of the conversation, it's more common to start with schemas for XML request and response streams. That decouples the client from the web service a bit more and allows any client that can send XML via HTTP and consume an XML response fair game.
how can i create an singleton asmx webservice ? (please don't say use WCF and WWF :D )
Short Answer: You don't want to.
Long Answer: A request to an .ASMX is going to non deterministically use a new worker thread, so even if you used the singleton pattern, the life of the singleton will not be known.
Perhaps elaborate on what you want to do, and I can guide you towards the best pattern.
I'm not sure how a singleton solves your performance problem, unless you are caching data inside the instance. In that case, I'd agree with the above suggestion of introducing the cache between the service and the database. Just how mutable is this data?
I won't suggest WCF, but only because you asked us nicely not to.
I will mention that you've found yet another reason to use WCF over ASMX. You might want to keep a list.
You might also want to keep a list of reasons to use ASMX over WCF. You might even want to use the same list for the reasons not to upgrade to .NET 3.5 SP1. It won't be a long list.
There may come a time, when Management wonders why certain things take so long to accomplish, when you'll want to send them your list.
You could use an ashx (HttpHandler). Implement IHttpHandler and set IsReusable to false.
http://neilkilbride.blogspot.com/2008/01/ihttphandler-isreusable-property.html
Depending on what you want to do, maybe you can write the engine as a singleton that's accessed by whatever thread services the ASMX call.