Silverlight企业应用实战:第二篇,方向

时间:2021-02-01 17:04:05

本篇博文推荐给开发经理、系统架构师和系统设计人员,希望SE的设计思路可以对您有所帮助。

 

“每一个应用的诞生,都为了解决某些特定的问题。这就是应用系统的方向。”

 

问题带来需求,需求带来方向。好的架构师必须首先了解系统的需求,进而才能设计出合适的结构。这个世界上永远没有“最好”的架构,只有“最合适”的架构。向不了解需求就开始设计的架构师默哀吧。。因为这样设计出来的架构必将是失败的。

 

SE的方向:

  1. RIA应用。
  2. 即时通讯。
  3. 企业信息(类邮件)。
  4. 业务应用。

 

RIA应用:

  • RIA应用类似与传统的C/S结构,应用系统中必须包含Client和Server。通讯底层将是系统的核心,可选方案有:WCF、RIAServices、Socket。
  • WCF:Silverlight对WCF支持的不好,当时(SL 3.0)可选的协议都是基于HTTP的,通用性好但是性能低下、速度缓慢。。。无法达到对于系统高效的要求。
  • RIAServices:Beta版本,很多都是不稳定的(就在几天前,2010年5月11日 RIAServices正式发布了1.0版本,并更名为WCF RIA Services,实际上起到数据访问的还是Asp.Net。)
  • Socket:成熟的技术。基于TCP/IP,收发消息速度飞快~可以满足系统效率的要求。问题是Silverlight不支持Listener,无法运行监听端口,因此必须维护客户端到服务端的长链接。维护长链接的开销。。如何保证复杂环境下长链接的可用。。都是难点。。

 

即时通讯:

  • 即时通讯在企业应用中非常的有用。SE是办公类软件,如果可以集成即时通讯,不但增强用户的粘度,更可将业务应用和即时通讯进行紧密的结合,创造出巨大的价值。
  • 即时通讯的基本功能:好友列表、对话、多人对话、广播、文件。
  • Silverlight不支持p2p,因此无法实现客户端之间的直接通信。所有的内容必须经由服务器转发,这会给服务器增加额外的压力。比较不一致的体验就是,局域网内的两个用户,传输文件也必须经由服务器中转,效率低下。
  • Silverlight的UI相当于单一页面,收到消息的提示是个大问题。(这个问题在SL 4.0升级后得到了一定的解决,OOB时MainWindow和NotificationWindow还是很好用的!赞一个!!我们将在下一版SE 4.0中应用大量Silverlight 4.0的新特性~尽请期待!)

 

企业信息:

  • 类邮件的系统很多的办公软件都有,但是到目前为止没有哪个应用系统的邮件体验可以达到网页版的Gmail、163或客户端的Outlook、Foxmail的水平。Silverlight给了我们一个机会,可以努力做到类似客户端的体验。
  • 邮件是一套非常复杂的系统,如果全部实现不是一家小公司短时间内可以做到的。但是客户又要求满足这方面的需求,而且这也是办公最常用和最基本的形式。再难也要做。。
  • 邮件基本功能:通讯簿、发出邮件、答复、全部答复、转发、收件人、抄送、附件、撤回。
  • 撤回:必须要着重讲一下撤回功能,撤回功能在企业应用中有着非常重要的作用。但是目前任何一个邮件服务的撤回都是难以实现的,因为发出去的邮件就像泼出去的水。。再要收回来就比较难了。由于我们没有去做一个传统的邮件系统,而是自己实现了一套“类邮件”,反而在架构上拥有先天的优势,因此相对容易的实现了撤回功能。
  • 存储、同步等。。都是难点。

 

业务应用:

  • 业务应用。系统设计之初没有太多考虑应用实现的问题。业务应用的实现只是底线,如何将业务应用和即时通讯和企业信息相结合,才是SE系统最大的亮点。当时想不过来这些,摸着石头过河,业务应用就被暂缓考虑的。

 

通过对需求的分析,我们最终选定为:Socket(自己实现通讯和服务调用,相当于完整的WCF体系)、即时通讯(自己实现Silverlight中的“多窗口”,通讯内容全部基于服务器转发)、企业信息(基于服务器的类邮件系统,存储、同步、分发等功能都自己实现)、业务应用(由于即时通讯必须要求“多窗口”,因此业务的UI也一定是基于“窗口”的)。

 

最终我们确定了两套框架:基于Socket的底层通讯及服务调用框架和实现一套“多窗口”的UI框架。

 

SE第一次确定了“方向”。