VB.NET版机房重构---验收总结

概述        经过20多天代码的编写和10几天的画图和文档的完善，这个个人版的机房重构算是基本完成了！但是经过验收以后，发现自己最大的问题还是在需求分析这一段，“需求搞的很混乱！”。 问题一： 看了我一开始的ER图以后就跟我说这个图问题很大！于是就在一起分析了一下这个图： 首先：这个图的实体很混乱，根本就没有把实体搞清楚到底是什么。 其次：“属性怎么还可以共用呢？” 最后：实体之间的关系起的名字 经过20多天代码的编写和10几天的画图和文档的完善，这个个人版的机房重构算是基本完成了！但是经过验收以后，发现自己最大的问题还是在需求分析这一段，“需求搞的很混乱！”。
问题一：
看了我一开始的ER图以后就跟我说这个图问题很大！于是就在一起分析了一下这个图：
首先：这个图的实体很混乱，根本就没有把实体搞清楚到底是什么。 其次：“属性怎么还可以共用呢？” 最后：实体之间的关系起的名字不好，让人一眼看不出两个实体之间到底是什么联系！
前两个问题好解决，而这第三个问题还是有点模糊！ 经过近两个小时的教育，总结下来就是：实体与实体之间的关系其实就是“主 谓 宾”的关系。比如：“学生使用卡”，和“卡属于学生”就不是一个概念。在这两个例子中首先看出：学生和卡就是两个实体，而“使用”和“拥有”就是两个联系！如果是“学生使用卡”，那么学生这个实体的属性中就得有卡号，代表这个学生使用的哪一个卡！而如果是“卡属于学生”的话，那么卡这个实体中就得有一个学号的属性，代表这个卡的归属者。所以一个数据库设计成什么样完全体现在这个ER图中，可见ER图中的任何一个名字都不是随便命名的！
接下来就是修改过的ER图：

问题二:

组长说：“你在做这个软件的开头的时候有没有改过路径？为什么要改路径？为什么在U层加配置文件，而不是在其他层？” 我一听，傻眼了，为什么要改路径？因为它出问题了，只有改了才可以解决问题！这下组长们都无语了，〒▽〒！ 回来后我查了一下：.net类加载的机制就是默认从本程序集的bin文件中找,所以bin文件夹中一定要有要加载的程序集的dll。只要 .dll 文件存在于 Bin 文件夹中，ASP.NET 就可以识别它。如果您更改了 .dll 文件，并将它的新版本写入到了 Bin 文件夹中，则 ASP.NET 会检测到更新，并对随后的新页请求使用新版本的 .dll 文件。（这只是原理，没有解决具体问题）
后来组长给的答案是这样的：我们在VS写的程序都是先编译再执行的，各层之间的引用在编译后都会在相应层中生成对应的DLL文件（即动态链接库），比如我们的机房收费系统中B层引用的Facade层并且间接引用的IDAL层，那么这两个层在编译后会在U层和B层生成相应的DLL文件。如下图：
B层的：


U层的：（在没有修改路径之前，是没有DAL.dll的，这里的图片是修改之后的）


这样当程序运行时，只用在U层找它需要的DLL文件执行就行了，但是，根据正确的 类图（与之前博客的类图有所不同，进行了改正）如下：
可以知道U层并没有对D层间接添加引用，所以在U层就不会有D层的DLL文件，所以在程序执行的时候会出现类似如下（路径问题）的错误：
解决方法为：把编译路径修改为..\UI\bin\DeBUG就可以了。这里的“..\”这表示的是上级目录。

关于配置文件为什么放在U层？道理和以上为什么修改路径一样，也是为了U层执行的时候方便，不用再去各个层去找DLL文件和配置文件来执行。这样，当程序打包的时候只用打包U层就可以了，因为U层具备了程序运行所需的各种DLL文件和配置文件！


小发现：配置文件可以分为好几种，可以放在不同的层中，各种用处都不相同，如果想了解，可以参考这个网页：http://www.oschina.net/translate/why-where-and-how-of-net-configuration-files
小结：
凡事总是要问一个为什么，可以让自己多了解一些更深层的知识，虽然这些知识我们不可能全都了解，但是知识的积累永远都不会嫌多，先吃下，再慢慢的消化！另外就是，需求分析很重要，合作的时候一定要好好的整理需求，需求整理好了，写代码的时间会大大缩短！ 总结

以上是内存溢出为你收集整理的VB.NET版机房重构---验收总结全部内容，希望文章能够帮你解决VB.NET版机房重构---验收总结所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。