咨询有关WCF作中间层缓存有关问题，欢迎讨论
咨询有关WCF作中间层缓存问题，欢迎讨论
大牛们晚上好，
由于不了解WCF的我现在想急切了解一下WCF，并且欲用于项目之中。所以有以下些许疑问，期待得到热心的您的指点，谢谢！谢谢大家！
1.使用WCF中间层缓存常用表数据，给Client频繁调用(非常频繁) 与 Client直接从SQL数据库查询该数据，二者在速度上有多大差距？
（我潜意识认为wcf会差太多,因为我测试从client调用wcf方法之计算两数之和,如此简单之功能，从调用到返回需要1秒时间。会不会太长？）
2.wcf能否保持连接状态(会话),类似TCP三次握手，而不是http那样每次重来。（估计是废话问题）
3.完！
欢迎讨论！
------解决思路----------------------
参考这里：http://www.cnblogs.com/artech/archive/2012/02/13/wcf-rest-conditional-retrieval.html
缓存就需要在客户端，那样最好，服务端缓存没难度，自己搞个静态的字典，按照Key来缓存结果集，唯一需要关注的是内存消耗，如果内存消耗过多，需要及时情况，而客户端缓存性能就高多了。
------解决思路----------------------
1. 如果你真的可以直接访问关系数据库，干么要用什么WCF呢？通常这是优先考虑业务环境约束的。例如有人开发一个游戏服务器，那么它可能暴露一个关系数据库api么？不可能。这时候它就需要自己定义自己的通讯协议，来提供api，这样他就能把握住服务接入技术的主动权。而如果你是把一个办公室里的小OA给弄到网上，那么你就给客户端直接提供关系数据库呗！反正这种网络软件也值不了几个钱。
2. 很显然，WCF甚至web service，都是非常非常慢的。你做几个tcp或者http服务器程序就知道了。还是那句话，这个要看你的开发时是有现成专业的通讯程序、还是随便找个容易上手的就行。
3. 尽管有人说WCF可以这个或者那个provider之类的，但是实际上没有几个人调通或者用好的。因此我们基本上可以认为WCF是基于http之上在慢个两三倍速度。所谓tcp三次握手，即使是http也是一样（毕竟http是基于tcp之上的）。但是如果你使用tcp，你可能是长连接的，也就是说仅需要在登录时握手，然后就可以并发地进行成千上万地双向通讯。而http不行。
4. 完！
------解决思路----------------------
基于服务的业务功能来设计服务接口，与基于所谓的数据库表的“增擅改查”来设计服务接口，在性能上没法比。这就好比如说高速公路上运送待销售的整装货物，每辆车都拉的是对方正好需要的货物。而后者，则是每辆车只允许拉小一堆零件而不允许拉整装的货物，虽然看起来好像挺灵活，其实每一个代理商都需要额外地多跑十次才能把一个货物拉准备好，反而是慢了。
但是我看你似乎并没有去从业务服务出发，而是从底层细碎的关系数据库记录出发去设计的。
就缓存来说，如过你说你不过只有一个数据表、这个数据表只有1000条记录，那么也就算了。如果你说你要缓存很大的内容，那么你认为要把整个内容都读取到客户端才叫缓存，这就很没有意义。你正是基于这个理由，才说“我认为缓存在客户端不太明智”这种话的。实际上因为你的缓存概念完全是错的，用来分析别的东西自然结论也往往就是错的。
比如说有一个数据有10万记录，而我的程序现在只是用过100条记录，那么我显然仅缓存了100条，用得着一下子缓存10万条么？如果缓存整个表，那么记录的命中率就几乎为0，还搞什么缓存？
------解决思路----------------------
WCF缓存与SQL区别在于，一个开销是序列化，一个开销是读硬盘(缓存未命中的情况下)。
抛开实际需求与运行环境，很难说清楚谁好谁差。
大牛们晚上好，
由于不了解WCF的我现在想急切了解一下WCF，并且欲用于项目之中。所以有以下些许疑问，期待得到热心的您的指点，谢谢！谢谢大家！
1.使用WCF中间层缓存常用表数据，给Client频繁调用(非常频繁) 与 Client直接从SQL数据库查询该数据，二者在速度上有多大差距？
（我潜意识认为wcf会差太多,因为我测试从client调用wcf方法之计算两数之和,如此简单之功能，从调用到返回需要1秒时间。会不会太长？）
2.wcf能否保持连接状态(会话),类似TCP三次握手，而不是http那样每次重来。（估计是废话问题）
3.完！
欢迎讨论！
------解决思路----------------------
参考这里：http://www.cnblogs.com/artech/archive/2012/02/13/wcf-rest-conditional-retrieval.html
缓存就需要在客户端，那样最好，服务端缓存没难度，自己搞个静态的字典，按照Key来缓存结果集，唯一需要关注的是内存消耗，如果内存消耗过多，需要及时情况，而客户端缓存性能就高多了。
------解决思路----------------------
1. 如果你真的可以直接访问关系数据库，干么要用什么WCF呢？通常这是优先考虑业务环境约束的。例如有人开发一个游戏服务器，那么它可能暴露一个关系数据库api么？不可能。这时候它就需要自己定义自己的通讯协议，来提供api，这样他就能把握住服务接入技术的主动权。而如果你是把一个办公室里的小OA给弄到网上，那么你就给客户端直接提供关系数据库呗！反正这种网络软件也值不了几个钱。
2. 很显然，WCF甚至web service，都是非常非常慢的。你做几个tcp或者http服务器程序就知道了。还是那句话，这个要看你的开发时是有现成专业的通讯程序、还是随便找个容易上手的就行。
3. 尽管有人说WCF可以这个或者那个provider之类的，但是实际上没有几个人调通或者用好的。因此我们基本上可以认为WCF是基于http之上在慢个两三倍速度。所谓tcp三次握手，即使是http也是一样（毕竟http是基于tcp之上的）。但是如果你使用tcp，你可能是长连接的，也就是说仅需要在登录时握手，然后就可以并发地进行成千上万地双向通讯。而http不行。
4. 完！
------解决思路----------------------
基于服务的业务功能来设计服务接口，与基于所谓的数据库表的“增擅改查”来设计服务接口，在性能上没法比。这就好比如说高速公路上运送待销售的整装货物，每辆车都拉的是对方正好需要的货物。而后者，则是每辆车只允许拉小一堆零件而不允许拉整装的货物，虽然看起来好像挺灵活，其实每一个代理商都需要额外地多跑十次才能把一个货物拉准备好，反而是慢了。
但是我看你似乎并没有去从业务服务出发，而是从底层细碎的关系数据库记录出发去设计的。
就缓存来说，如过你说你不过只有一个数据表、这个数据表只有1000条记录，那么也就算了。如果你说你要缓存很大的内容，那么你认为要把整个内容都读取到客户端才叫缓存，这就很没有意义。你正是基于这个理由，才说“我认为缓存在客户端不太明智”这种话的。实际上因为你的缓存概念完全是错的，用来分析别的东西自然结论也往往就是错的。
比如说有一个数据有10万记录，而我的程序现在只是用过100条记录，那么我显然仅缓存了100条，用得着一下子缓存10万条么？如果缓存整个表，那么记录的命中率就几乎为0，还搞什么缓存？
------解决思路----------------------
WCF缓存与SQL区别在于，一个开销是序列化，一个开销是读硬盘(缓存未命中的情况下)。
抛开实际需求与运行环境，很难说清楚谁好谁差。