Diagnostics总结(三)

前言

我已经写了三篇博客了。看到每篇都有7至9个人浏览过，自己心里还是有点开心的。虽说写的比较烂，但还是希望这些博客对读者能稍微有点用处。

技术这种东西越学的深越觉得自己渺小，越觉得需要掌握的东西还有很多。以前我也想把自己编程中积累的一些经验记下来保存到印象笔记中，但是后来发现这些东西记完之后根本不会再去看第二眼，而且要说记的话也只是复制黏贴别人的东西。所以想到要把记的东西写成博客，至少博客别人还会去看，自己总归还是要点脸的，总要把样式整的好看些，而且这也是一个知识重组的过程，有助于自己的记忆。所以说写博客算是为了自己也算是回馈大众- -。

数据库安装

Diagnostics是一个环境安装工具，其中需要安装的就是数据库。我们使用的数据是Sql Server——一个相对来说比较重型的数据库- -。有安装Sql Server经验的都知道安装过程是一个比较复杂的过程，要选实例名称、用户名密码之类的东西。更要命的是这东西是客户使用的，不见得让用户配置这些东西吧。
其实微软早就考虑到这些问题了，它可以通过参数来指定安装过程，通过进程启动SqlServer的安装包可以通过Aarguments设置启动参数

arguments=" /Q /ACTION=Install /SECURITYMODE=SQL /SAPWD=""123456"" /INSTANCENAME=""ExpertTest"" /SQLSVCACCOUNT=""NT AUTHORITY\NETWORK SERVICE"" /SQLSYSADMINACCOUNTS=""BUILTIN\ADMINISTRATORS"" /IACCEPTSQLSERVERLICENSETERMS=TRUE /TCPENABLED=1 /INDICATEPROGRESS" process.StartInfo.FileName = fileName; process.StartInfo.Arguments = arguments;

把数据库安装在客户环境下面，这种情况我也是第一碰到过。这种情况有几种弊端：

1. 安装：安装时不能让客户接触到太机密的信息，比如数据库密码、表结构等等。SqlSever有这种集成化安装功能，我不知道其他数据库会不会有。
2. 更新：如果版本更新得把数据库和程序同时更新。
3. 安全：如果程序卖的比较多，只要破译一个数据库，所有的产品就没有机密可言了。

抱怨了这么多，但实际解决方案也不多。我们的产品主要安装在工厂里不具备网络条件，无法做成分布式的- -.

数据库升级方式

随着应用软件的升级，数据库自然也需要升级换代。而且我们这个产品升级还是相当频繁。以前我做过的项目，因为只有一个数据库，数据量也不多每次升级都是通过手动添加删除字段来控制的（我承认当时我比较Low）。现在这款产品升级都是通过脚本来进行升级的，而且每个版本都做了版本控制。

在工厂这个环境，升级当然是需要自动化，不能给别人一个脚本就完事（不人性化也不安全）。我认为的工厂升级流程是这样的。

在Diagnostics程序框架中Script文件是以 Embedded Resource 方式嵌入到 加密Dll中的，这种方式解决了安全的问题。只要程序判断数据库中的Version与当前程序中的Version不一致。它就会去执行预置的脚本。

数据库和程序一起升级这种应用场景让我联想到了之前研究过的Entity Framework中的 Code First 这种开发模式。在这种模式中数据库的构架完全都是通过程序控制，包括迁移、回滚、升级。如果运用这种模式就省去了数据库脚本的相关操作，只需对程序做相应的修改，保证了程序的一致性。我之前使用的数据库是Mysql，实践中出现有些不兼容的情况。SqlSever这种原生的数据库支持应该会很好。以后可以试一下。