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

前端之家收集整理的这篇文章主要介绍了VB.NET版机房重构---验收总结前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
经过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

小结:

凡事总是要问一个为什么,可以让自己多了解一些更深层的知识,虽然这些知识我们不可能全都了解,但是知识的积累永远都不会嫌多,先吃下,再慢慢的消化!另外就是,需求分析很重要,合作的时候一定要好好的整理需求,需求整理好了,写代码的时间会大大缩短!
原文链接:https://www.f2er.com/vb/257526.html

猜你在找的VB相关文章