请教精通WCF的技术大牛。

[Generics]

我现在需要用WCF作一个同步服务，就是把客户端的数据库和文件跟服务器的数据库和
文件相互更新。我们的客户都在条件特别恶劣的地方，也就是说，网络的带宽不仅窄，
而且流量费用巨高，所以需要尽量减少流量。我们公司的技术大牛（Lead Developer)
已经做过类似的同步服务。他的做法如下，不管是数据库的数据，还是文件，他都把它
们转化成byte[]。如果是数据库的数据，他把它们压缩成byte[]，如果是文件，就把他
切成一块一块（chunk)传送，我查了一下他的设定，绑定直接用的是wsHttpBinding,里
面用的都是缺省的设置。我想问一下大牛，他的这种做法有没有问题啊？

我这两天一直在琢磨，上网查资料，我总感觉数据库的数据和文件应该分别对待，数据
库的数据可以用wsHttpBinding,但是文件应该用Stream来传输（wsHttpBinding不支持
Stream),现在的问题是basicHttpBinding的Security好像不容易搞定，要知道，上传/
下载文件也需要传递用户名和密码，然后根据服务器里的数据库数据来决定是否授权。

请指点迷津。

[以专业开发人员为伍]

为什么总是你“觉得、觉得”的呢？人家都已经做好了的东西，而你没有成功做出来过，为什么靠猜测就来说人家是非呢？ 如果要真正去分析，前提是，你写出来一个实现方法和几个测试实例，然后再来说人家的方案跟你的方案的区别问题。我们不可能忽悠一个做不出来东西的人，去反对人家能够做出来东西的人（哪怕是人家设计的东西并不好）。

[以专业开发人员为伍]

如果判断一个公司挤走了能干点事儿的人、而用离实际“执行力”渐行渐远的人来接手时候，我们就不主张动手修改人家的程序了。你要先保证立刻（当天）拿得出你的解决方案来并且运行成功，再来修改人家的程序。

[本拉灯]

为毛非得用HttpBinding,用NetTcpBinding不就可以实现你说的Stream传输么。

[Generics]

我对wcf不熟，虽然以前也做过一点，但都是简单的以样画瓢，但wcf深层的东西缺乏了解。

我现在的位置确实非常尴尬。因为我做的确实是别人以前做过的东西，只不过他们以前做的东西基本不能用，一方面三天两头崩溃，另一方面设计不合理，不仅界面不友好，而且非常不好用。

所以大老板对以前的程序员非常非常的不满意，开了几个，只留下一个LEAD做维护，因为他们干了七八年，写了好几个系统，除了我现在正在写的一个（他们写的那个系统，客户端还在用，服务端一直就没人用），其他的还在运行（三天两头crash, 所以把大老板气得不行）。

我现在写的系统，一切都是推倒从来，数据库都大不一样（因为大小老板的要求是forget about the old system! 事实上原来的代码也非常难读和难维护。)

我现在困在wcf这一步，现在新系统是我一个人写，一个商量的人都没有，有心找那个LEAD商量，人家采取的是冷淡和不合作态度。

我现在是压力山大，上司催促我尽快完成。真想骂娘了，老系统据说花了四年时间，现在新系统我一个人才做了半年，而且每周都有新要求新花样，上司都是技术盲，真以为他们要什么我马上就能给他们实现(我不是大牛，工资基本上是我们组最低的）。

我只是希望精通wcf技术的，能给我出出主意。我初步的打算是，在继续沿用老系统的办法的同时，增加直接传输文件的服务，这样将来也可以做些比较，做些选择。

[Generics]

老系统的办法，事实上问题很大。他们一方面把文件切割成块，另一方面把数据先放进datatable里，然后再放进dataset，最后压缩成byte[]，放进buffer里（连username 和password 都放进人为建成的data table里），wsHttpBind好像是自动压缩的吧？

[software_artisan]

验证其实可以很简单，wcf接口参数里面包含登录名和密码hash就行了。至于压缩也很简单，微软提供了一个Gzip的样例，一般的数据压缩率是10%以下，10M的数据实际传输不到1M。别的你就不用纠结了，二进制肯定是数据量最小的。

[娃都会打酱油了]

不同的绑定方式传输速度不一样的

[moonwrite]

数据库的话，本来一些数据库就有同步的数据的功能，去查询这方面的资料吧 文件的话，用FTP不是挺好的么，如果可以的话，自己写Socket更好了

[wjq]

做法没什么问题。文件切块是避免太大导致传输中断而重新传输之前传过的内容。 stream本质也是byte[]，只是它对调用者隐藏了分批的I/O操作；且WCF记得你用stream类型，客户端引用的时候也是作为byte的，这个你不要纠结这种对你的问题来说无关紧要的部分。 如果你非要改进，可以给数据库加CRC或者其他类型的校验，避免数据因为恶劣的网络环境而出错（其实主要是校验完整性）。其次，可以考虑压缩数据流。一个WCF传输的数据（XML）使用zip压缩后可以缩减到原来的1/10（我的项目中的测试结果）

[Generics]

谢谢楼上的各位，现在我决定基本沿用原来的办法，文件切块，数据压缩，不过因为客户端用的是Access数据库，服务端用的是SQL Server, 所有做成Datatable再压缩好像没有意义，也许直接压缩类更好？

[Generics]

谢谢楼上的各位，问题已经基本解决。经过我的调查和研究，我还是彻底摒弃了原来切块用buffer的做法，改用steaming的做法，经过初步测试，效果还不错。用户信息和文件信息都是自己加密以后放在message的header里。