Using Attributes in WebService

The way the Web publishes a method in WebService is simple, just identify the method you want to publish with the System.Web.Services.WebMethodAttribute attribute class, but the attribute can only be applied to a method and not to a property. The MSDN documentation for this class is visible (C #):
[AttributeUsage (AttributeTargets.Method)]
public sealed class Webmethodattribute:attribute
So, what if we need to publish a property as a Web method? Before discussing this issue, let's take a look at why we need to publish the property as a Web method? Because someone might tell you this, you can rewrite your attributes into two corresponding getxxxxx/setxxxxx methods to publish them separately as WebMethod. Oh, yes, this may seem to be the end, but doing so undermines our interface definition, making it impossible for us to enjoy the happiness that attributes bring to us (please don't ask me what happiness is), but one of the most important reasons is that I can't finish the implementation of the interface. And look at the following code (C #):

public interface Idataservice
{
This property indicates what database system is currently in use (for example, Ms-sqlserver, Orcale, IBM-DB2, and so on)
int Dataprovider
{
Get
}

The method executes a specified SQL script and returns its result set
System.Data.DataSet Execute (String sqltext);

This method saves the specified dataset to the database
void Update (System.Data.DataSet DataSet);
}

Now we're writing a WebService. It needs to implement the Idataservice interface, which must be included and published in the WebService. What should we do then? Oh, and see

public class DataService:System.Web.Services.WebSerbice, Idataservice
{
...

public int Dataprovider
{
[WebMethod (messagename= "Getdataprovider")]
Get
{
...
}
}

[WebMethod ()]
Public System.Data.DataSet Execute (String sqltext)
{
...
}
}

OK, as you can see, publishing a method as a Web method specifies the WebMethod property before its function body, and the property specifies the WebMethod property before its get or set, and if you do not specify the MessageName property value of the property, The Web method name of the published property is placed as Get_xxxxx and set_xxxxx.

The members in the WebService proxy class generated using vs.net (by adding Web references, Reference.cs) are methods, so you need to manually modify the related methods in the proxy class as properties, such as the code for the local proxy class in the previous example looks like this:

[System.Web.Services.Protocols.SoapDocumentMethodAttribute (...)]
[Return:System.Xml.Serialization.XmlElementAttribute ("Getdataproviderresult")]
public int Getdataprovider ()
{
Object[] results = this. Invoke ("Getdataprovider", new object[0]);
return (int) results[0];
}

So you just have to change the main part of the method to this:

public int Getdataprovider
{
[System.Web.Services.Protocols.SoapDocumentMethodAttribute (...)]
[Return:System.Xml.Serialization.XmlElementAttribute ("Getdataproviderresult")]
Get
{
Object[] results = this. Invoke ("Getdataprovider", new object[0]);
return (int) results[0];
}
}

You can use the attributes in WebService by using the above steps. Oh, happy and back again!



Something:
During the development process, you may need to publish new methods to your WebService page frequently, and the client program also needs to sync update WebService to get the latest interface, and when the client refreshes the WebService reference, your proxy class loses the changes you have made. You can maintain a client proxy class and compile the proxy class into a separate class library, and all clients that need to refer to this WebService can simply reference the proxy class in that class library, which prevents multiple developers from synchronizing changes each time the WebService reference is updated. and simplifies the release of WebService. Of course, in this way you need to seriously consider your class library version and some of the namespaces of the strategy, which is quite interesting and full of artistic things.
In addition, about WebService page size (including the number of methods) and performance problems also require us to pay enough attention to this aspect of a suggestion please refer to my log: http://blog.csdn.net/sw515/archive/2004/07/ 20/46349.aspx