敲七层登录的时候。忽然间认为敲三层搞清的思路瞬间又凌乱了。花了一天的时间边敲边梳理，最终整完了，执行的时候弹出了这种错误：未能载入文件或程序集“DAL”或它的某一个依赖项。
系统找不到指定的文件。
“载入”二字引起了我的注意，可是我并不知道它的载入机制，于是便去询问度娘了，度娘首先说明了产生错误的原因：
1、DLL文件名称与载入时的DLL文件名称不一致。
2、DLL文件根本不存在，即出现丢失情况。
3、载入DLL路径错误，即DLL文件存在，但载入路径不对
依照度娘给出的原因，我去检查了前两个问题，发现那不是我的项目报错的原因，于是将目光定格在了第三个问题上。但是载入路径是怎么回事呢？这便涉及到了反射的一个原则:一切皆以UI层的bin目录中的dll名称为中心。(原因非常easy:.net类载入的机制就是默认从本程序集的bin文件里找,所以bin目录中一定要有要载入的程序集的dll)。【UI层中bin目录中要载入的程序集的dll叫什么名字AssemblyPath就使用什么名字,bin内部要载入的类的全名叫什么，className就写成什么全名。
.net中的引用:增加对某个程序集的引用就能在程序集有变化时自己主动拷贝dll。】
相信看了上文，即便不知道怎样解决，也能知道解决这个问题的方向了。关于此问题的解决的方法有两种，各自是：
1、把DLL层的以DAL命名的文件拷贝到UI层的debug中。
2、改变DAL层的生成输出路径。
解决方式我们既然有了，能肯定的一点是，都能解决这个问题，可是论解决这个问题的长久性，还是另外一种更好，为什么呢？
依照第一种解决方式，执行程序，输入username和password。系统真的会提示“恭喜你，登录成功！”。问题看似攻克了，事实上这并非根本。把程序中的代码随意改错，又一次执行还会提示“恭喜你，登录成功！
”，这是怎么回事？打开UI层debug，发现除了DAL的dll文件的全部其它文件都是随着解决方式的生成而生成的。这么说直接拷贝是不行，治标不治本。
这就引出了另外一种解决这个问题的方案，改变DAl的生成输出路径，改为UI层的debug文件。再又一次生成解决方式。文件的生成时间都一致了。执行就没有问题了。
综上所述：我们解决这个问题的关键就在于让文件的生成时间一致，步调一致，执行无忧~
文字要是看着太多。请原谅我让尊贵的读者大人遇到bug后急于找到解决的方法的烦躁心情愈加凌乱，于是我决定“负图请罪”：
上述问题解决后。为了让自己对7层的理解度加深些。我開始着手里边相对较小的功能——改动password，就在我把代码敲完后。执行时出现了这种问题——输入的原password即便和当前用户的password不一致，也能改动成功。
关于改动password功能，我的大概思路是这种。先推断输入的原password是否和当前用户的password一致。然后再推断password是否改动成功。然而出现了上述问题。我也非常纳闷。这两条线的代码思路是一样的，代码实现大同小异，既然可以提示我改动成功，说明不是代码的问题，于是，我便对推断原password那条线进行了分步调试，走到BLL层弹出这样一个错误——源文件与模块生成时的文件不同，指向了C:Users秋若枫Desktop机房重构七层V1.0——孙利楠ChargeReBuildDAL，然后询问我：仍要让调试器使用它吗？（PS:我哪知道？！）
于是乎，我又投入了度娘的怀抱，找到了解决的方法。首先打开自己的DAL层的目录，例如以下：
然后，删除如图所看到的的三个文件。又一次生成解决方式。
最后，打开UI层，进行下图说明的操作。
当我完毕上述操作后，再执行程序。假设原始password输入错误，就会有对应的提示了～
关于调试器调试的提示：工具-> 选项-> 调试-> 常规 ->把“要求源文件和版本号匹配”的勾勾去掉->然后去掉“地址级的调试”的勾勾（这样就不会出现反汇编代码了。这一步可不要），然后又一次引用。
改动password功能的实现，巩固了我敲登录时候的理解。对接下来的功能的实现，有点迫不及待了，系统。也是我们的small baby~