MyGeneration学习笔记(9) ：在WebService使用dOOdad时,对ToXml/FromXml的一点改进

       在前面几篇《在Web Service中使用dOOdad》中，我提到用ToXml/FromXml来实现在WebService中使用dOOdad。但在具体的项目实践中，我有遇到一个新问题：将一个业务实体ToXml后得到字符串，然后再对FromXml来解析字符串，获得新的实体，但这个实体已严重失真，其中的DataTable丢失了Schema，会导致部分数据类型(如数据库中的Image类型)对应的字段不能解析回来，这时调用Save方法时就会出错。

dOOdad项目源代码中的ToXml和FromXml：

virtual public string ToXml()
}

 

       针对如上所述问题，我的一个解决办法是重新构造Schema。下面是我的大致思路：

//BusinessEntity中：
virtual public string ToXml()
}

 

//ConcreteClass中：(ps:建议在ConcreteClass中实现自己的代码,而不要把自己的代码写到dOOdad生成的AbstactClass中;因为如果数据库中表的字段作了局部调整后,AbstractClass中需要作很多琐碎的改动，倒不如删掉AbsractClass重新再用MyGeneration来生成代码,而自己加入的代码又得重新写过。)

public override void AddNew()
 

      现在就可以通过ToXml和FromXml来实现字符串(不含Schema)与业务实体的近似对等转换(注意:这里仅仅是说近似对等转换，因为DataRow的状态还是丢失了，所以在FromXml后，CurrentRow的状态处于Added；此时如果是想实现对数据库记录的修改，则还需调用AcceptChanges()和SetModified()(MyGeneration学习笔记(6) ：在Web Service中使用dOOdad(下) 有讲)重新设置其状态才实现修改。)

     补充：上面所讲的是实现在网络中只传输DataTable中的数据，而不传输DataTable的Schema。事实上，dOOdad中已实现了另一种方法来实现字符串(含Schema和数据)与业务实体的转换,即Serialize()和Deserialize()方法，且这种序列化是高保真的，可以使得业务实体通过XML字符串实现完全对等转换。但这种方法的一个不足之处是传输数据时需要传输Schema,我试过用Serialize()序列化我的项目中的一个业务实体，得到的Xml字符串的长度是3460，而ToXml()得到的字符串的长度是1857，二者相差1603个字符。一个Unicode字符占4个byte，则每次Serialize()得到的结果要比ToXml()得到的结果大1603*4Byte(大约6.26k)；而当系统中很多个客户端同时请求这种获取数据的WebMethod接口时，就不得不考虑WebService服务器的网络负担了。