康盛创想—UC必定是个失败的战略。

1、性能瓶颈，UC的整合用的是网站操作网站然后再操作数据库，打个比方说论坛和SS的同步，登录论坛，然后论坛向UC发信，UC再向SS发信，最终实现统一登录。这中间有4个验证过程，第一个是论坛数据库信息的验证，第二个是论坛和UC间的秘钥验证，第三个是UC和SS的秘钥验证，第四个是SS的数据库信息验证。而现在的论坛和SS的整合只用了1个验证，其他的是靠的公用COOKIES实现同时登录的。
也就是说如果用UC整合论坛和SS的验证步骤多了4步，并且每增加一个模块都要再增加两个验证，这样能保证速度和稳定性吗？据我所知各个模块和UC的通信比PHP直接操作MYSQL要脆弱的多，如果网络不好很容易出现通信失败，不知道UC是不是用的SOAP或者ajax，以前动易动网和OBLOG的整合就经常出现通信失败的情况。

2、扩展性混乱，到底用户表的哪些信息放在UC里面，哪些放在各个模块里面，很难统筹，用户表的字段一多起来，如果用户在一个模块修改个人信息同时还要修改UC里面的信息，同样的步骤要做两次，光理清UC和各个模块间存储内容的关系就陷入混乱了。

3、UC的长处在什么地方？DZ现在推出的UC战略有点制定业界标准的味道，以后开发任何WEB程序只要按照UC的标准来开发，都可以即插即拔，就像电脑的USB接口，非常方便，这就是UC的长处。比如帝国、DEDECMS等程序如果按照UC的标准来开发，用户可以很方便的安装或卸载这些模块，而不影响网站的用户系统，不用再做整合。
但是，前提是得帝国、DEDECMS给你配合才行啊！！！他们开发程序会完全按照康盛公司制定的标准吗？他们会跟着大C的指挥棒走吗？他们愿跟别人做嫁衣裳吗？如果他们设计用户表会以自己的程序为中心还是以UC为中心？显然他们会按照自己程序的需求来设计。
如果UC只是用在康盛公司内部的几个模块的整合，就完全没必要了，既然用COOKIES就可以实现同时登录退出，还用UC这么麻烦干嘛？干脆像现在这样用一个统一的用户表，任何一个模块都用这一个用户表算了，还要各个模块设计操作自己的用户表干嘛？这不是舍近求远吗？

4、UC对于菜鸟的价值，菜鸟不会写程序，都是用现成的就算DZ给出了API标准对他们来说一点意义也没有，他们根本不会用UC去二次开发。

5、UC对于高手的价值，既然高手能看得懂UC的API标准，能开发出来接口，肯定也会修改模块程序了，与其修改程序修改接口实现用户数据同步，他们不如直接修改所有的模块都取读一个数据库了，那样只要设计一个用户表就OK了，修改用户数据的时候只要修改一处程序就可以了。就像一个屋子里的两个人，说话对面说就行了，还用得着拨打手机吗？

现在来看DZ有把自己的未来押在UC上的意思，感觉这样太危险了，至少我的网站我要观察1到2年看看别人的效果再说，想当年动网动易OBLOG的整合也是前途一片光明，但结果并不理想。

哦?很深奥的说.....

现在的DZ太娱乐化了，不适合技术雷的站，特别是什么游戏功能以为这样就是为站长着想？再说站长赚钱也不是这样啊！太幼稚了！

确实，新版本的DZ越看越不顺眼....:10fsdf

关键是他想像微软一样垄断的占领市场，这个把戏就是搞捆绑！

关键是他想像微软一样垄断的占领市场，这个把戏就是搞捆绑！

呵呵 长见识了

新来的 报道先