[讨论]讨厌或不懂WCF的进

LZ这种以Stream流处理也是对大量消息数据传递处理的一种解决方案

WCF做做300以下并发量的应用可以用用。做高并发，高吞吐量的程序，最好不要选这个。否则再多钱都不够烧。呵呵，经验之谈。

我更讨厌必须明确返回值类型这点现在只能用Json数据做返回值在SL前端解析很是不爽

局域网内使用直接连接数据库的方式就可以了。
一般使用wcf是广域网。
wcf是网络拥堵的时候，效果真的不是很好。
wcf没有深入研究。自己做的wince上的程序比较多。所以自己写了一套通信协议。
http://www.cnblogs.com/dataexcel/archive/2012/12/09/2809045.html

还是喜欢使用Socket, 虽然WCF相当方便.

另外,WCF的定位并不是单纯的数据交换或者是消息传递.
在EAI中项目中使用WCF, 才可以更好更全面的诠释WCF的优雅.

中国的网络条件不乐观啊，上行带宽能有个10M已经很不错了，如果服务端上传量很大，肯定来不及处理，而对于数据库的瓶颈几乎可以忽略，一来可以使用缓存，对经常访问的数据存放到内存里；二来可以使用IDataReader进行枚举数据发送，简单点说，就是100万行数据要发送，读取第一条就开始发送了，发送和读取是同步的。
WCF不开源和限制多是它的失败支出，设计思路很好，但是就算使用自定义绑定，能做到的也很有限，所以说那个只能用来学习，大项目要使用的话，得考虑折衷方法（自己处理序列化过程，返回stream）。顺便补充下，其实WCF的那个序列化还有个问题，在对Dictionary进行Json序列化时，返回的格式很不爽:
[{"Key":"ID","Value":1},{"Key":"Text","Value:"gg"}]
别说看起来不爽，用起来也不方便，明明那个Key是不可能重复的，而且.NET里面不可为空（Java中可以为空），那么不是可以作为匿名类型的属性来处理吗:
{"ID":1,"Text":"gg"}
而第三方的Json序列化类对于匿名类型的序列化和反序列化，就自动映射到这样的一个Dictionary<string,string>类型上的，因此替换WCF自带的序列化类是非常有意义的。

受教了感觉wcf不是很好用

WCF的确性能不行，但用起来方便，真是爱恨交加，不过设计思路如楼主如说，是值得学习。因此学习WCF对设计会有一定的提高。

只用过几次wcf，发现数据量大的时候传输速度会变慢，当时还不知道怎么解决......
如果以后还需要用到wcf，还得好好研究研究

WCF 是工业规范，有分布式事务，有安全机制，还要考虑多种通信协议的统一编码风格，消息体自然复杂而又庞大。分久必合，合久必分，就像WebApi脱离WCF。大一统的框架未必适合所有的开发需求。

其实我是不满意微软的那个自定义绑定——CustomBinding，这里有个自定义绑定编写的示例。只能通过override进行自定义的设置，而且还必须严格遵循他给定的规范，比如他通过WrapperEncodingBindingElement替代原来的MessageEncodingBindingElement来实现消息序列化过程的控制。然后在看WrapperEncodingBindingElement类，返回MessageEncoderFactory，再通过WrapperMessageEncoderFactory返回WrapperMessageEncoder，最后由WrapperMessageEncoder对消息进行编码解码，也就是所谓的序列化。要干预序列化过程也只能在这个地方进行了。接着断点在WrapperMessageEncoder的WriteMessage方面，可以发现，无论我使用的是Json还是Xml的序列化类，最终这个参数message已经是被xml序列化后的内容了，无法再此之前进行任何干预。再看这个示例：    public override XmlObjectSerializer CreateSerializer(
                Type type, XmlDictionaryString name, XmlDictionaryString ns,
                IList<Type> knownTypes)
    {
        return new NetDataContractSerializer(name, ns);
    }
要将默认的序列化替换掉，还必须返回XmlObjectSerializer的派生类，这下我彻底理解那个DataContractSerializer或DataContractJsonSerializer的使命了，与其说是序列化类，不如说是格式化类，将已经序列化到xml格式Message对象，格式化到指定类型上，从而导致了无法使用第三方快速序列化类进行替换，更不能直接实现边序列化边传递消息，因为消息本身就是已经序列化好了的。
微软在WCF编程规范中，限制死了序列化过程，只能让你改变序列化的格式Formatter，而不能直接替换序列化行为。Gzip压缩也是在格式化消息的过程中进行干预而已。微软只考虑了规范，没考虑性能，开放的自定义绑定必须遵循规范使用，无法使用Emit进行最高速度优化。.NET4.0一开始的性能迟问题导致发布延也是一个例子。总结：C#语言本身是高效率的，但是微软的的框架却让它工作在低效率下面了，还不让别人去从根本优化它（不开源），所以我们可以学习微软的框架，实际使用就需要打上个问号。看似非常好用的内置类，反编译下看看实际是如何实现的，效率如何？只求稳定而不考虑效率的，就没必要看它的实现，微软的框架的稳定性的确是考虑的最好的。最后推荐下一款国外著名的开源框架，对于性能追求者是个福音。其性能和灵活度都非常高，采用了Java中广泛使用的IOC思想,是替代WCF的最佳选择。（把Java的优秀思想拿来为.NET服务，又不失.NET的高效性）

无法想象用 WCF 发送100W行数据，如果楼主写了这样的代码，那很明显不是 WCF 的性能问题，而是使用不当的问题。DataContractSerializer 在控制 xml 格式方面提供的选项非常少，这是有意为之的，目的是将程序员的注意力拉回到数据契约的业务含义上，而不是物理表示上。如果很关心传输的格式，或者有大量数据要传递，那么 WCF 可能不合适。在思考怎么使用 WCF 传输几百 M 的数据时，请记住 WCF 采用的是契约优先开发方式，目的是简化跨进程跨平台调用，它不是 FTP 的替代品。

什么叫使用不当，大数据量传输和FTP根本是两码事，如果只是传输文件，使用FileStream，无需序列化，根本不存在效率问题。但是我这里是业务需要读取数据库，比如异地数据库备份，或者业务系统通过外网访问,C/S结构访问WCF服务。数据量大是很正常的情况，如果是直连数据库，可以边度边异步加载数据，我要做的是让WCF完全替代直连数据库，使用者感觉自己就好像直连数据库。这个根本不可能用FTP替代。

<- 不懂wcf
最近正在学习socket，楼主能提供点资料吗

楼主应该是wcf方面的专家，刚好我有一个这方面的问题求解决，在论发过帖，地址如下：
http://bbs.csdn.net/topics/390408695

场景一：前人写了个C/S系统，直连数据库的，每个位置一个数据库，但是互相间数据需要同步，自带的同步工具经常出错，遇到几千资料要同步的时候，同步几个小时都不会好，当然上行才50K，但是要时时同步数据没办法，用WCF代替吧，那个序列化后的数据不减少体积一样会很慢。
当然，对于ADSL来说，需要数据库信息交换的时候，50K上传显然不够，必须考虑压缩数据量。不然别说10W了，1W就可以崩溃。
场景二：并发数100的情况并不少见。如果没个请求返回1000左右的数据条数，那么10W就有了，如果数据提及是100M那么光网络上传输都要几分钟时间，但是如果数据量压缩到原来的1/10，那就只要几十秒时间，大大提高了数据响应速度和降低并发冲突。

场景三：服务器只有4G内存，但是为了缓存部分请求结果，内存不能随便浪费。如果用默认的消息处理方式，对象本身占一份内存、序列化到Message后再占一份内存、发送数据又占一份内存。如果数据量大，发送耗时长，内存暂留时间偏长，服务器内存消耗严重。如果把第二份内存省略，第三份内存占有也压缩，只有对象本身占用内存，而那部分又可以作为缓存来使用，下次请求直接读取而不访问数据库，充分利用服务器内存资源，做到不浪费，否则再大的内存都不够用。反对频繁调用GC.Collect()来释放内存。

我开始确实有点讨厌，现在无所谓，开始讨厌是因为感觉把html语法嵌入。

曾经买了一本关于WCF的书想起来还没怎么看

调试易

[讨论]讨厌或不懂WCF的进

解决方案 »