这个只是随便拷了两行代码，不在一起，我看网上说用泛型集合代替DataTable，您觉得那样是否更好一些

 另外还需要大量的遍历操作

因为还需要将数据通过wcf返回给客户端，服务器上通过泛型集合做处理，最终将泛型集合转换为DataTable返回客户端这样是否可行，返回对象的话将来接口扩展很不好

@MSky: 是否使用泛型需要看你的场景，比如你数据就那么几个不变的字段，就自己定义一个对象来存放吧，泛型在这块没多大用处。就算变化多也是要看具体情况，泛型本身可以理解为一个模板，如果你这些有共性，能够通过组合泛型及抽象派生提出相关功能再考虑也不迟。

比如

interface IFoo

{

　　bool IsValid();

}

class Bar:IFoo{...}

class Baz:IFoo{...}

bool CheckFooIsValid(IEnumerable<IFoo> foos)

{

　　return foos.All(f=>f.IsValid());

}

但如果你各种数据之间没啥关系，就没必要用泛型了。

遍历操作这个不用太过于担心，cpu计算本来就是cpu的强项，如果真的出现性能问题也没特别好的方案，无非就是优化算法，拆分数据多进程或者并行处理。

@Daniel Cai: 实在抱歉，我光考虑1没考虑2，因为还需要用到排序，看来还是要用DataTable,忽略了这点

@MSky: 在接口交互上用DataTable这些玩意我是极不建议的。原因如下

1.这些弱类型与接口契约本身就相抵触，契约就是要严谨，不应该存在多义性，这样才能确保交互时候的安全性，不然你丢个这个玩意过来除了私下约定好里面会是啥外没有其他方式来保证这玩意打开后不出现意料之外的情况，这个和前段时间某人在博客园发了一篇文章，洋洋洒洒的在所谓的通用的api接口中写个大大的object一样的情况。虽然看起来通用，但这样的通用又有什么意义呢。

2.DataTable/DataSet在原生支持的几种序列化下性能，速度，大小上都不敢恭维，ms在很久前为了这个问题还专门写过一篇文章针对这个做了一个方案，大体上就是再定义一个对象，只保留最基本的数据信息，把这两个玩意里面其他极可能不用的东西全部丢掉（比如schema信息），然后在服务端返回前把数据从datatable/dataset写到这个对象里面来，客户端拿到后再重新写到datatable/dataset中去。绕了这么一大圈不就是为了规避datatable/dataset在序列化时候的问题么。

3.由于上面的序列化导致垃圾会堆的很快，gc这个时候很够呛，高负荷下gc时间会让你很蛋疼的，之前维护过的项目就由于这个慢的出翔啊，dump出来的文件windbg看了后里面大把大把要回收或者进到下一代的字符串（当时使用的xml序列化）

4.dataset在原生的序列化中跨版本的向下兼容性很差，可以说是没有，你要是从个framework3.5下返回一个dataset，4.0+的framework会因为找不到system.data(找2.0版本，4.0下当然没有）报错。

@MSky: 排序这个又如何了？难道就是看中了datatable中那个可以用字符串写个类似sql语句的玩意？

放弃吧，.net中lambda+expression已经顺手的不像样子了，写这个不比那个字符串有趣些么？何况性能上远比那DataTable.Select要好。

@Daniel Cai: 好，我学习学习，以前没了解过lambda表达式