使用FDO封装XML&ADO实现与服务端数据通信

FDO第一个问题就是安全性，难道我要在客户端拼装SQL？ 那是很不现实的问题，这样似乎太不安全了，很明显。所以应该使用暗号，外加参数。比如说，一个暗号：show me the money

可以对应一个SQL语句：select * from money where user=’?’,这种写法有点类似java中的PreparedStatement 中SQL的写法，？可以用参数代入。呵呵，这是我比较幼稚的一个想法。在服务端可以建立一个暗号(Command)与sql相对应的一个表（可以用数组实现），这样当客户端有请求的时候可以根据这个暗号来查询SQL。在一定程度上避免了恶意的SQL输入。其实FDO不仅仅是Flash(Client)中的FDO，她应当还要包括服务端的FDO，我这里使用了ASP，用服务端的FDO类来封装ADO，所以在服务端几乎无须涉及ADO只要调用用FDO方法或过程就可以了。那就先来说说 Flash端(Client)的问题,客户端FDO可以位于FDO包中可以包含以下几个类和一个包含文件：

·包含文件：声明作者和版本信息，以及公用函数等。

·FDO.as：这个文件中定义FDO类，完成与服务器的数据交互。

·Command.as：用于生成操作命令，并提交到FDO类。

·RecordSet.as：使非常容易的获取接收到的XML中的数据，类似ADO中的RecordSet对象。它被设计成只读。

·Record.as：定义Record类，这个类主要是在更新和插入数据时作为参数输入。

在这里，我把RecordSetlei类设计为只读，我觉得修改它的数据没有任何意义，因为它不会主动更新数据库。其最主要的原因就是网络延时，任何一次与服务器的交互都需要等待时间。当我们把程序的主动权交给Flash Player之后（Flash Player要等待服务器反馈，然后调用onData onLoad之类的事件），只有当Player调用数据下载完成的事件以后，Flash的继续播放才是有意义的，原因很简单：如果你不给我数据，我怎么往前走！所以既然FDO类是直接与服务器交互的，那么就应该为FDO定义回调的事件，以供FDO用户重写这些事件。这些事件的目的就是：等待数据或操作（即与服务器的交互）完成后，继续驱动Flash的播放。这一点，很好理解，我们通常都会用一个下载过程在片头，等下载完成后在往后面播放。道理是一样的，没有服务器数据，播放很有可能出错，所以Flash要等到服务器数据到达以后才把主动权叫交给用户（指开发人员），用户可以重写回调函数。

与服务器的交互通常包括四种：查询、插入、更新、删除。只有查询才返回用户（开发人员）所需要的数据，其他的操作返回一个操作结果就可以了，比如说，更新了几条记录，插入数据是否成功，或者在操作过程中发生了一些不可以预测的错误，这些错误都应该返回给Flash客户端，以便开发者进一不处理，或者把错误告之应用的最终用户。这些都保证了程序的健壮性。

[1] [2] [3]  下一页