一步一个脚印－产品升级随笔（2）－为什么需要BS架构的产品

昨天加班将近7：00，一群人主要是讨论产品由CS结构转向BS结构的问题，争论的很是热闹，为什么非要用BS架构取代好好的CS架构呢？

一个兄弟的设计中十分强调WebService，建议将所有的服务全部封装为WebService，这样Client端无论采用什么方式都可以了，呵呵，多理想的想法，是呀，如果把所有的服务都这么做了，Client确实可以支持多种方式，可是代价是多大呢？这就需要将公司的产品全部推倒重写，公司现在的产品已经开发和运营了3年左右了，但是用户的需求和产品升级的压力还是很大，如果全部废弃掉，我想，没有1年的时间，产品是不可能制作出来的。

而且公司的产品中有一个链条特别需要关注，就是“消费品”，如果我们的产品不提供足量的、高质量的数据，产品的竞争优势很低，因此将CS中的数据迁移到BS中，还是一个很头疼的事情，而且十分重要。

公司产品的使用者主要是两个方面：1个是数量不是很多的管理者，一个是数量众多的使用者。而转向BS架构的应该是数量众多的使用者，因此经过讨论我们将注意力转向使用者前端的应用上，而将数量极少的管理者的功能暂时不作修订，而维持原装，这样升级的压力就降了下来。

在大家达成一致将炮火转向使用者的前端应用上的时候分歧又产生了，就是采用什么模式进行设计。

在兄弟的设计中提出了3种架构：（1）RIA（2）纯Web方式（3）Activex控件＋Web

经过讨论我们基本认可了采用第3种方式，由于公司的产品最大的特色必须需要进行本地控制，就像杀毒软件一样，如果用户不能杀本地的病毒，只能杀服务器上的病毒，我想产品也别想卖了。

在将目光转向Activex控件上后，问题就又出现了。

从用户角度来看，用户选择BS架构主要就是减轻客户端的安装压力，用户总是抱怨CS架构的安装压力太大，而且升级更是怨声载道，因此很多用户提出了BS模式。

呵呵，但是由于公司的产品需要处理本地的东西，因此如果采用BS架构的方式，Activex的安全性和权限就很难说了，而且Activex控件的稳定性则需要我们尽一步加强。

但是由于客户机器本身保护的原因，Activex控件的下载也许用户的体验并不是很好，因此通过对产品的分析，基本上确立如下的原则：

（1）尽可能的减少Activex控件的尺寸，利用VC或者Delphi重写Activex控件，以加快Activex控件的下载速度。

（2）将功能分解，通过增加Activex控件数量的方式，来避免一次下载大Acitvex控件的方式。

（3）通过流程控制，只下载需要的Activex控件，而不是一次下载所有的控件。

（4）通过UI设计，提高用户体验，减轻控件下载的用户抱怨，并通过UI指导或帮助用户解决由于Activex控件问题造成的使用障碍。

（5）Acitvex都需要有一个Test函数，用来测试控件是否可以正常工作。

（6）以IE5为基准进行测试。

由于这些天再看《网站重构》这本书，也建议采用Web标准进行设计，别一开始就走上一条混乱之路，另外在这本书的封底说这本书是“博客园”推荐的，呵呵，我怎么在园子里没有发现呢。

在考虑兼容性上，我们基本否定了Sql2005的使用，呵呵，这个东西也许需要过一段时间才行，否则如果装了我们的系统对别的系统造成影响可就坏了。

还有，就是先前兼容的问题，呵呵，兄弟的计划是逐步将老产品改造成一个全新的产品，因此十分想改数据库的结构，这恰恰是不能接受的，最后的妥协是这样DAL层，还是按照新的设计走，但是对旧结构做兼容，能提供的提供，不能提供的按照接口作出默认值，呵呵，暂时只能这样了，目前还不是特别清楚。

估算时间，呵呵，兄弟总想立刻就开始Coding，唉，如果好好看看《Joel说软件》，也许就不会有这个冲动了，还有就是看看《克制Coding的冲动》，解决的办法是又配置了一个师兄，逐步分解他的烦恼，通过配对讨论来使架构逐步清晰。

这些只是昨日的想法，也许通过不断的调整、组合和分析，一切才逐步完美。