原文：http://blog.csdn.net/guxch/article/details/12162131
六、一个最简单的实例
Thrift文件（demo.thirft,来自官网）如下：
- struct UserProfile
- {
- 1:i32 uid,
- 2:string name,
- 3:string blurb
- }
-
- service UserStorage
- {
- void store(1: UserProfile user),
- UserProfile retrieve(1: i32 uid)
- }
运行
- thrift –gen cpp demo.thrift
则生成的文件如下：
- demo_constants：这个文件似乎没有用，可以在其中定义全局变量之类的东西。
- demo_types：类型定义（例子中的structUserProfile）都在这个文件中。
- UserStorage：这个文件比较重要，内容比较多，其中的内如下图。图左边是两个service方法的传入传出参数，注意其中每个的实现都有两个，一个是带p的，被用在客户端代码中，另一个是不带p的，被用在服务器端代码中，其实它们的代码相当一致（相同的函数部分），不知道thrift这样做的用意在哪。图右边UserStorageIf是消息接口定义，UserStorageIfFactory等是接口的“工厂”。UserStorageNull挺有意思，大概是什么都不做（既然什么都不做，要它做什么呢？）。UserStorageMultiface是将多个UserStorageIf集合起来（vector）处理。对用户来讲，客户端真正有意义的代码在UserStorageClient中，写客户端时，需要认真查看其接口，在其上编写自己的业务逻辑。服务器的处理过程在UserStorageProcess类中（但我们自己逻辑在另外的地方）。
- UserStorage_server.skeleton：这个是服务器端的框架（其实它可以运行），我们自己的逻辑（例子中store到数据库中或从数据库中retrieve）在UserStorageHandler类中实现，这个类从UserStorageIf继承而来。文件中还有一个main函数，其中给出了以TSimpleServer形式（单线程）实现的服务器。实际的应用中，UserStorage_server.skeleton这个文件将被拆分，业务逻辑可能有若干文件，服务器端的实现也许要复杂一些，与其他业务构成一个main函数，这里的main可能叫做thriftserver_main更合适一些。
需要强调的是，thrift有自己的网络传输格式，因此thrift应用适合于我们不关心传输过程，只关心我们自己的应用层的消息的传递（也就是RPC的概念）的场合，如果规定了网络传输协议，thrift并不适合。
其他实际的应用见hadoop和Hbase的Thrift接口说明。
【注：本文参考了Mark Slee, Aditya Agarwal and Marc Kwiatkowski写的“Thrift:Scalable Cross-Language Services Implementation”一文，该文是Thrift的White Paper。】
