评论

2010-04-15 11:28  

xx搞不懂的路过           

2010-04-15 13:20  

觉得将用户会话信息和业务放在一起不怎么好，应该有个会话服务，统一管理用户会话信息。           

2010-04-15 13:26  

汗……技术点……

不用webservice的话，可以考虑下WCF
虽然效率高不了多少就是了
而且只布到一台机器上有点浪费

话说组件怎么样都好，关键的还是具体子服务端的实现吧
一般来说，网络通信很少有冲突，短信的话……看用什么群发器（好像是这么叫）再具体说吧           

[楼主] 2010-04-15 13:43  

业务部署要求 不需要应用不是部署在多台机器上。

再说：我们的目标就是在同一机器上 多个应用调用同一组件。

问题的关键在于;

有什么方式可以启动组件，同时又可以给好多应用共享。这个是问题所在           

[楼主] 2010-04-15 13:45  

by52911
WCF 在性能要求高的场合 是没有什么用途的
同时 注意：WCF 和Web服务的机制是一致的           

2010-04-15 13:59  

WCF Named Pipe Binding           

2010-04-15 14:00  

WCF没什么用处……看来是百万级了……
这个咱就无能为力了，坐等答案           

2010-04-15 14:10  

既然都是在同一台机器上，那么共享内存可能是最快的方式。
将会话信息单独分离出来，可以创建一个windows服务来管理。
业务组件不需要单独能够执行，由三种连接服务端根据需要直接调用。业务组件通过内存共享来访问由windows服务管理的会话信息，当然业务组件要提供会话编号。           

2010-04-15 14:10  

楼上这个不对，WCF在远程调用中是效率{zg}的。WCF的目的就是构建高效、安全的远程调用机制，比其他的方式慢就不对了。楼上说的WCF和WEB服务的机制是一致的这就更不对了。你可以看看下面这个link

这里面给出了WCF和WS, .NET remoteing之间的详细性能比较。

WCFxx基于可配置的，所以不同配置下得到的性能是差别很大了，具体要看你的配置情况。           

2010-04-15 14:14  

其实同一台机器， wcf的命名管道方式性能应该也不差吧。           

[楼主] 2010-04-15 14:23  

恩 WCF的管道方式可行。
查了一下：管道方式 是通过共享内存的方式。性能的角度来讲 问题就不大了           

2010-04-15 14:32  

WCF是用来解决所有通讯问题的框架
设计的初衷就是

"框架里的零件经过替换和自定义开发
可以处理所有的通讯场景"


所以说用不用WCF其实不在本讨论之内 如果lz决定了最终的方式 就可以按照wcf的框架组织实施。

lz还是不要受到干扰 确定自己要用什么连接协议和数据协议先           

[楼主] 2010-04-15 14:46  

韦恩卑鄙 v-zhewg @waynebaby
感谢你的关注：

我前面关心的其实是 框架中 服务器端 各种服务应用共享交互信息的问题。
在框架设计中 包含了多个服务应用。对于和客户端交互的连接，我是放在各服务应用中考虑。
具体的通信协议看具体的业务而定。

对于WCF框架 一说 本人有自己意见：
WCF 不等同于框架。
我的理解WCF MVC，还有Castle 等等 。是实现框架的技术手段。

框架是比这些概念更高，更宏观的层次。他的基础出于业务需求=业务功能+质量+约束。




          

2010-04-15 14:50  

对你的意见微笑 抱残守缺也是个人的选择啊
          

2010-04-15 14:59  

连接协议：
TCP
UDP
内存共享
命名管道 （基本上要用这个了）
消息队列
HTTP
HTTP RESTFUL

数据协议：
Json （推荐用这个）
Xml
Soap
.net Binary
Struct Mashal
HTML
IMIX
自定义数据包



都定下来以后 全部自己写还是用WCF自己实现部分零件/用别人提供的部分零件 悉听尊便^_^           

2010-04-15 15:01  

no, WCF是框架无疑。Windows Communication Framework，这是Framework，和MVC之类的xx不同的。比如{zd0}的电子产品零售商NewEggs(新蛋)，就全部使用的WCF，性能产生问题，通常不是框架本身的原因，有些细节没有注意到，就会产生性能损耗。

我楼上的发言确实不是针对楼主议题的，而是针对5楼回复的，现在流言满天飞，但是没有人去讨论这些流言是真的是假的，所以对于5楼信口就说WCF在高性能场景下就没什么用途了，感到非常遗憾，这貌似不是做技术的态度。           

2010-04-15 15:04  

用JSON就需要用WCF3.5 SP1，JSON支持是3.5 SP1新增的特性，可以解决传输数据过大的问题，毕竟JSON数据相对还是比较简洁的。           

[楼主] 2010-04-15 15:17  

韦恩卑鄙 v-zhewg @waynebaby

哈哈 我对XX框架有很深的感触，我亲手经历过好多项目，业务不是太复杂，但上了XX“框架"后 ，复杂度直线上升。
原因很多。
但根本上有一个共同的现象：业务去适应XXX“框架”。
就像给个模版，答题一样。
现在这样的现象在身边还是时有发生。

我们在这边谈XXX“框架” 主要是观察的层面 还是基于实现的角度。

在实际项目实施中，实现框架 的前面还有很多东东，企业框架，业务需求，概要框架设计 等。




          

2010-04-15 15:24  

这里有一个人御剑还是剑御人的问题。
包括模式啊 包括类库啊
当你无法与其交互 为其扩展的时候 往往是变得不方便时候。

比如asp.net Mvc 在大家因为不能强类型的使用helper的时候 老赵就写出了表达式缓存和强类型访问扩展。像我这样的人就要等将近两年。

但lz因此抵触框架 就有点因噎废食了


顺便吐槽楼上某 WCF的F似乎不是Framework


但是呢 我自己觉得吧.net framework 内部的东西 都是框架的一部份 嘿嘿。

          

2010-04-15 15:31  

2010-04-15 15:37  

话说 Remoting的问题是 MashalByRefObject 太慢，而不是tcp速度慢。 才不作为{sx}的。           

[楼主] 2010-04-15 15:45  

韦恩卑鄙 v-zhewg @waynebaby
哈哈 不好意思
我想海砍一下子 ，没有砍好。

上面 关于框架的问题 收回。           

[楼主] 2010-04-15 15:49  

哈哈 博客园 还是不错的 基本上还提供聚会的机会，现在片片数语，不尽其意。 真想参加一下子。           

2010-04-15 16:04  

boring.... 搞了半天还是MS的。我还以为是自己的技术。           

2010-04-15 16:18  

辰
不知道辰桑对 EF4 的自定义T4模板有什么独到见解啊 等您发文呢