视乎最近写文太少,又手痒,故而借助本次安装与升级模块所遇问题写点更多介绍。

上帝给了两只耳朵和一张嘴巴,因此文并非介绍界面,更多的是技术层面方法。

一、那个……我们用什么姿势

故事的开始,然后……直接结束,这好像是越来越多安装或升级过程的趋势。对于中间运用什么姿势完全不让客人理会,看起来很简约也很省事。

其实中间多少姿势对于技术而言是等同,不管中间要不要告诉客人进行到什么程度了,结束报告是必须的,不然怎么收费呢?

ASP.NET天生强悍以一敌多(即:多线程)。目前我们的做法是:首先将整个过程放入一个新的线程里,然后客户端通过AJAX定时拉取来报进度。

这种才算是一个完整的异步。至于C#的Asyn或Ajax请求都不是真正的异步,即使在服务端使用异常调用方法也是服务端的事,跟客户端完全无关。

而另一重要问题,线程是无法访问 System.Web.Current 属性,所以传递信息只能依靠 HttpRuntime.Cache

二、蛋疼的数据库更新

数据库安装及升级有几种办法:

1.附加,安装时很好,但升级呢?
2.通过生成脚本执行*.sql文件,很强大可以做任何你想做的事,但要注意角色。
3.利于程序来组织各种Schema,反正我看到workpress、DNN都是这种方案,但是如果代码组织能力不好反而变得更麻烦。

目前选择就是第2种办法,但会遇到一些问题,譬如:生成的脚本无法在SqlCommend来执行,原因是当遇到GO时会抛出【GO附近语法错误】异常。

解决GO问题

采用的方案是将GO行做为分段条件,然后逐一执行每一段代码,实验结果是通过SQL SERVER生成的脚本可以完整的更新。但必须注意生成脚本时一些索引、默认值等也要一并加上。

必须要加事务,否则就是灾难。

执行*.sql的其他方法

1.通过“osql.exe“来执行整个*.sql文件,这就不会有GO问题。
2.利于Microsoft SQL Server Management Studio提供的各种API接口,但分析发现不同版本有不同的DLL,所涉及的DLL合起来是MB大小,要有良好的支持,各种版本的考虑,算了,不想了。

三、资源文档部署问题

产品化会涉及的很多资源文档。如何管理这些文档让升级变得高效。这里会分为服务端【指提供者DDN部署】和宿主端【直接存放于产品端】,会有几个问题:

1.更新频率,比如我们是基于Bootstrap,那么大可放在服务端。
2.版本更新频率,对于频繁就为宿主端。
3.带有静默升级功能,大可完全基于服务端。

为什么提倡服务端部署,特别是对于有大量JavaScript脚本产品,原因是统一部署可以提供更健壮、更快速响应服务。而且如果是由JavaScript引起的又不影响业务的Bug可以直接修正,何乐不为。

暂且列为三点我认为较为需要考虑用户体验问题吧。