在阅读之前，请先阅读我写过的第一篇有关Indigo的文章.
Data Contract是用来定义Indigo Service与Client端之间用来交换的数据的格式，如果我们需要传递自定义的数据，那么就需要将其定义为符合Indigo规范的Data Contract。数据里面的每一个数据项，被成为Data Member。
[DataContract]
public class UserInfo
{
[DataMember]
public String FirstName;
[DataMember]
public String LastName;
[DataMember]
private DateTime Birthday;
}
上面的代码示范创建了一个UserInfo类，并且使用“[DataContractAttribute]”特性对类进行了修饰，对于需要被加入到Contract中的数据项，也使用“[DataMemberAttribute]”特性进行了标记。
得注意的是，UserInfo有一个特意的设计，那就是Birtyday这个属性，其访问域被定义为private的，但是我们仍然使用了“[DataMemberAttribute]”来标记它。private的访问域控制并不会影响其成为Data Contract中的一个Member。一个属性即使是public的，但是如果没有被“[DataMemberAttribute]”来标记，那么这个属性也不会成为Data Contract中的一个数据项。就是说，我们可以认为基于类的可见性控制，和其是否是Data Contract中的一项Data Member是没有关系的。属性的值是否会在Indigo Service和Client间进行传递，只和它是否是属于Data Contract中的一项Data Member有关系。
然后我们开始定义Service Contract：
[ServiceContract]
public interface IProfileService
{
[OperationContract]
UserInfo GetUserByID(Int32 userID);
}
public class ProfileService : IProfileService
{
public UserInfo GetUserByID(Int32 userID)
{
UserInfo user = new UserInfo();
user.FirstName = "Kaneboy";
user.LastName = "Tu";
user.Birthday = new DateTime(1979, 1, 1);
return user;
}
}
上面的代码创建了一个IProfileService接口，然后定义这个接口为Service Contract，接着通过一个ProfileService类实现IProfileService接口，让其成为Service Contract的具体实现类。像这样将Service Contract定义在一个接口上，而并非是一个具体的类上，是更常见的方式。
由于这篇文章将重点放在Data Contract的定义之上，所以Indigo Service剩下的.svc和配置文件的内容，就不再详叙，大家参考上一篇Indigo的文章即可。
我们创建一个Console成为作为Indigo Client，通过svcutil这个命令行工具，自动生成所需的proxy类文件。在自动生成的文件中，我们可以找到UserInfo这个类，由于它被定义成为了Data Contract，所以svcutil会自动帮我们创建它。svcutil的使用方法和客户端app.config的定义，也请参加上一篇Indigo文章。
最后，我们在Main()中调用Indigo Service：
ProfileServiceProxy proSvcPrx = new ProfileServiceProxy("IProfileService");
UserInfo user = proSvcPrx.GetUserByID(1);
OK，我们成功验证了Data Contract的概念和基本的使用方法。下一篇Indigo参考系列文章，我将讲述如何在Client端不使用svcutil.exe这个工具，而手工书写Service Contract和Data Contract，以进一步验证Service和Client端交换的是Contract和Schema，而并非Class，这样一个基本理念。