经过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文件。如下图:
后来组长给的答案是这样的:我们在VS写的程序都是先编译再执行的,各层之间的引用在编译后都会在相应层中生成对应的DLL文件(即动态链接库),比如我们的机房收费系统中B层引用的Facade层并且间接引用的IDAL层,那么这两个层在编译后会在U层和B层生成相应的DLL文件。如下图:
B层的:
关于配置文件为什么放在U层?道理和以上为什么修改路径一样,也是为了U层执行的时候方便,不用再去各个层去找DLL文件和配置文件来执行。这样,当程序打包的时候只用打包U层就可以了,因为U层具备了程序运行所需的各种DLL文件和配置文件!
小发现:配置文件可以分为好几种,可以放在不同的层中,各种用处都不相同,如果想了解,可以参考这个网页:http://www.oschina.net/translate/why-where-and-how-of-net-configuration-files
小结:
凡事总是要问一个为什么,可以让自己多了解一些更深层的知识,虽然这些知识我们不可能全都了解,但是知识的积累永远都不会嫌多,先吃下,再慢慢的消化!另外就是,需求分析很重要,合作的时候一定要好好的整理需求,需求整理好了,写代码的时间会大大缩短!