Legendary WCF (5): data protocols ()

The legendary WCF (1): Is this hard to learn?The legendary WCF (2): What about service agreements?Legendary WCF (3): multiple protocolsLegendary WCF (4): send and receive SOAP HeadersLegendary WCF (5): data protocols ()Legendary WCF (6): data protocols (B)Legendary WCF (7): "one-way" & "two-way"Legendary WCF (8): Play with message protocolsLegendary WCF (9): stream and file transferLegendary WCF (10): message interception and tamperingThe legendary WCF (11): Session)The legendary WCF (12): What is the use of server callback?Legendary WCF (13): group chat programThe legendary WCF (14): WCF can also be used as a chat program.

 

 

In article 1, we have blown up the sending/receiving SOAP header. Starting with this article, we may wish to explore in depth what the messages in WCF are. WCF is huge and complex, and from the msdn document, you will see many very professional and abstract things. You can't help but ask, is what is mentioned in the document useful? There are still some practical theories, but some points are too abstract. Sometimes I don't know what to do with them?

However, data protocols should be useful, at least frequently used when you write a WCF Service.

 

Let's start with an example, no matter what the data protocols are.

1. Run vs as an administrator. Note: Run vs as an administrator. Otherwise, the server may not be started later.

2. Our example (solution) contains two projects: the server side and the client side.

3. I use console applications for simple startup.

Server implementation:

First, define a simple class employee. Now we only define this class in the normal way, And do not add the Data Protocol feature. In the server method protocol, return an employee instance to the client. We will test whether the call can be successful without declaring a data agreement.

Public class employee
{
Public string name {Get; set ;}
Public int age {Get; set ;}
}

 

The implementation of the service agreement is as follows:

[Servicecontract]
Public interface iservice
{
[Operationcontract]
Employee getaemployee ();
}

Public class myservice: iservice
{
Public Employee getaemployee ()
{
Return new employee {name = "", age = 32 };
}
}

 

Class Program
{
Static void main (string [] ARGs)
{
Uri url = new uri ("http: // localhost: 1233/services ");
Using (servicehost host = new servicehost (typeof (myservice), URL ))
{
// Bindong
Nethttpbinding binding = new nethttpbinding ();
VaR Ep = host. adddefaendendpoints ();
Servicemetadatabehavior MB = new servicemetadatabehavior ();
MB. httpgetenabled = true;
MB. httpgetbinding = binding;
Host. description. behaviors. Add (MB );
Try
{
Host. open (); // open the service
Console. writeline ("service started. ");
}
Catch (exception ex)
{
Console. writeline (ex. Message );
}
Console. readkey ();
}
}
}

Run the command to make sure the server can be started properly.

 

Next, let's take a look at the client. To add service references, go to the server debugging directory (bin \ Debug), run the management identity on the server, and return to, add a server reference to the client project.

After successful addition, write the client implementation code:

Static void main (string [] ARGs)
{
WS. serviceclient Cl = new ws. serviceclient ();
Console. writeline ("the service method is being called ...... ");
Var em = Cl. getaemployee ();
Console. writeline ("employee info \ n name: {0} \ n age: {1}", Em. Name, Em. Age );

Console. readkey ();
}

Make sure that the server is still running, and then debug and run the client. If the communication succeeds, you will see the following results.

 

This example only shows that if there is a non-primitive type in the Protocol method, the corresponding class can be generated when the client references it. At least it indicates that the serializable type is correct. What is a non-primitive type is the simplest type of CLR, such as int, bool, float, long .................. datetime is also said to be.

Let's look at the class generated by the client.

Different from the server, the class implements two interfaces: iextensibledataobject and inotifypropertychanged. If you think it is hard to understand, you can ignore it because it does not affect our practical application.

 

Next we will modify the code. on the server side, we will redefine the employee class. This time we will use the data protocol to mark it.

[Datacontract]
Public class employee
{
[Datamember]
Public string name {Get; set ;}
[Datamember]
Public int age {Get; set ;}
Public String city {Get; set ;}
}

Run the command again. Note that the service reference of the client must also be updated. Then run the client. On the surface, it seems that there is no difference from the previous use of data protocols. However, you should take a closer look at the definition of the employee? There is a city attribute in the definition of the employee class. However, after the client updates the service, there is still no city attribute in the code generated by the customer. In other words, only members who have applied the datamember feature can be considered data members.

Now, let's modify the employee class to add the datamember feature to the city attribute.

[Datacontract]
Public class employee
{
[Datamember]
Public string name {Get; set ;}
[Datamember]
Public int age {Get; set ;}
[Datamember]
Public String city {Get; set ;}
}

 

Then update the service reference of the client to see if the generated proxy Code does not have the city attribute?

This time, the city attribute is displayed in the code generated by the client. Therefore, we now understand that using data protocols can flexibly control which members should be recognized by clients.

In fact, data members can also be used for fields, even private fields. Let's take a look at the changes below.

[Datacontract]
Public class employee
{
[Datamember]
Public string name {Get; set ;}
[Datamember]
Public int age {Get; set ;}
[Datamember]
Public String city {Get; set ;}

[Datamember]
Private string _ address;
}

Now, the employee class has a private field as a data member to check whether the code generated by the client has changed.

We also see this private field. However, it is because it is private property and you cannot use it directly. Okay. Now let's modify the employee class.

[Datacontract]
Public class employee
{
[Datamember]
Public string name
{
Get {return this. _ name ;}
Set {This. _ name = value ;}
}
[Datamember]
Public int age
{
Get {return this. _ age ;}
Set {This. _ age = value ;}
}
[Datamember]
Public String City
{
Get {return this. _ city ;}
Set {This. _ city = value ;}
}
// Field List
[Datamember]
Private string _ name;
[Datamember]
Private int _ age;
[Datamember]
Private string _ city;
}

What code does the client generate this time?

We found that no matter whether we define data members as public or private fields on the server side, all data members on the client side become public attributes. To verify this, we modify the employee class again and change all the members to private fields.

[Datacontract]
Public class employee
{
[Datamember]
Private string name;

[Datamember]
Private int age;

[Datamember]
Private string city;
}

Because private fields cannot be accessed externally, you must modify the service code.

Public class myservice: iservice
{
Public Employee getaemployee ()
{
Return new employee ();
}
}

 

In this way, we can see what code the client will generate.

Obviously, all data members on the client become public attributes. What will this do? In fact, data protocols are transmitted through XML. If you think about the characteristics of XML serialization, you can find some inspiration. XML serialization and deserialization are only for public members. Therefore, if you want to serialize private data members as well, you can turn all data members into public members. This is also described in msdn.

 

There is also a good use of data protocols, that is, hiding identities. For example, we make the following changes to employee:

Public class myservice: iservice
{
Public Employee getaemployee ()
{
Return new employee () {name = "Xiaohu", age = 32, city = "Nanjing "};
}
}

[Datacontract (name = "worker")]
Public class employee
{
[Datamember (name = "worker_name")]
Public string name {Get; set ;}

[Datamember (name = "worker_age")]
Public int age {Get; set ;}

[Datamember (name = "worker_city")]
Public String city {Get; set ;}
}

This time, the Class, Class Name, and attribute name generated by the client have all changed. Although it has changed to another class, the data in it is still transmitted from the server-side employee class.

Therefore, data protocols can also hide real identities.

 

 

Turn to it