【个人机房重构】—— 抽象工厂+反射+配置文件详解以及错误分析

喜欢ヅ旅行 2022-08-11 11:29 102阅读 0赞

**背景**：我们现在写的程序，用的数据库基本上都是SQLServer的。试想一下，如果我们以后还需要开发同样的程序，但是，所使用的数据库不同。那时，我们应该怎么做？是重新进行开发呢，还是在原有程序的基础上进行修改呢？

在个人版的VB.NET的机房收费系统中，针对上边提到的问题，我们应该如何去解决。下边，Answer出场，Question退下。

# 一、Answer #

在这里，我们可以运用抽象工厂+反射+配置文件来解决上述问题。详情：《[谈一谈：抽象工厂+反射+配置文件 实现数据库访问][Link 1]》

# 二、New Question #

问题解决了，但是，随着问题的解决，随之而出现的是新的问题。

先来看一段程序：

Imports System.Configuration    '配置文件命名空间
    Imports System.Reflection       '反射命名空间
    Imports IDAL                    '引用接口层
    
    Public Class DataAccess
        '程序集名称(同时代表命名空间名称)：DAL
        Private Shared ReadOnly AssemblyName As String = System.Configuration.ConfigurationManager.AppSettings("assname")
        '数据库类型：Sql
        Private Shared ReadOnly db As String = System.Configuration.ConfigurationManager.AppSettings("DB")
        '创建D层类SqlUserInfoDAL的实例
        Public Shared Function CreateUserInfo() As IDAL.IUserInfo
            Dim dalUserInfoName As String = AssemblyName & "." & db & "UserInfoDAL"        '要实例化的D层类的名称
            Return CType(Assembly.Load(AssemblyName).CreateInstance(dalUserInfoName), IUserInfo)
        End Function

对于学过反射+配置文件+抽象工厂实现数据访问的人来说，这小段程序还是很容易理解的。我将这段程序用在了机房收费系统个人重构版中。如图所示：

![SouthEast][]

但是在运行过程中却报了错：

**   “未能加载文件或程序集“DAL”或它的某一个依赖项。系统找不到指定文件。”**

通过查资料，知道了一种解决方案：**将DAL层的DAL.dll文件复制到UI层相应的目录下**，如图所示。

![SouthEast 1][]

之后，程序正常运行，并通过CreateUserInfo（）创建出了SqlUserInfoDAL的实例。

有了成功的经验，我便做了如下操作：

*  在DAL层，添加了一个新的类：SqlWorkLogDAL
 *  在DataAccess中，添加了一个新的方法：CreateWorkLog（）

如下所示：

![Center][]

'创建D层类SqlWorkLogDAL的实例
        Public Shared Function CreateWorkLog() As IDAL.IWorkLog
            Dim dalWorkLogName As String = AssemblyName & "." & db & "WorkLogDAL"          '要实例化的D层类的名称
            Return CType(Assembly.Load(AssemblyName).CreateInstance(dalWorkLogName), IWorkLog)
        End Function

但是运行后，还是报了错，不过这次错误不一样：

**   ****“未将对象引用设置到对象的实例。”**

通过查资料，也找到了答案：**修改DAL层--属性--编译--生成输出路径，将生成输出路径改到UI层\\bin\\Debug文件夹下。**

虽然两种解决方法不一样，但是本质都是**把DAL层的DAL.dll文件放到UI层**。

**那么，为什么第一种解决方法只有“短暂疗效”，而第二种方法可以“根治”呢？**

这时，我做了个尝试，我不去修改路径，而是再次把DAL层中的DAL.dll文件复制并替换我刚才复制到UI层的文件。

结果成功了。

这就说明了：两次复制的文件并非同一个文件，虽然它们都叫DAL.dll,但是在文件内部，它们一定发生了变化。

这里我们就要说说，dll文件是怎么生成的了。

每个程序集下面都有两个文件夹bin和obj，如图：

![SouthEast 2][]

bin目录用来保存项目生成后程序集，obj目录用来保存编译结果。编译是分模块进行的，编译整个完成后会合并为一个.dll或.exe文件保存到bin目录下。而且采用**增量编译**的方式。

所以，当我添加了一个新的类SqlWorkLogDAl后，生成的DAL.dll已经不是原来的DAL.dll了。

复制的方式的缺陷在于：只要DAL层发生变化，就得通过手动复制来更新U层的DAL.dll文件。但是修改路径，就不用我们管了，它会自动将最新的DAL.dll文件生成到UI层。

**那么为什么要把D层的.dll文件在U层生成呢？**

这就要知道Assembly.Load（）是怎么定位程序集了？

当你只给定程序集名称时，如“DAL”，那么CLR只会在应用程序的目录下查找，而咱们的应用程序在UI层，所以要在U层有DAL.dll。

**    **问题又来了：

**    在U层，有Entity.dll,有BLL.dll,有DataAccess.dll……为什么就是没有DAL.dll,为什么只有它需要修改生成路径？**

这里就要看看程序的包图了：

![SouthEast 3][]

---->代表依赖，也表示引用，那么从UI层看，UI层可以直接或间接地引用Facade层，BLL层，DataAccess层，IDAL层，但是没有引用DAL层，所以别的层的.dll文件会出现在U层，而DAL层的.dll文件没有出现在U层。

# 三、反思 #

在使用抽象工厂+反射+配置文件时，我也遇到了上述的问题。当时为了解决问题，在网上查资料，咨询别人，最后也把问题给解决了。但是，在看到上边这篇关于如何解决问题的博客时，我陷入了深思。

我记得米老师曾经给我说过：不会，可以去问别人；但是问别人问题的同时，也必须要知道人家为什么会知道这个问题的答案，人家是从哪知道的。

我们在遇到问题的时候，都会去考虑怎么去解决问题，不管通过什么方法途径，基本上到最后，问题都能被解决。但是，有时候我们欠缺的是，深层次的思考。针对一个问题，可能解决了，就没事了，基本上不会去想：会不会有别的方法、途径，也能达到同样的效果？

在遇到问题时，应该抓住问题，进行深层次的发掘，多角度的思考。

学习，不仅要知其然，还要知其所以然。

转自：[徐晨阳：应用反射+配置文件+抽象工厂时出现的错误和原因分析][Link 2]

[Link 1]: http://blog.csdn.net/haovip123/article/details/38758685
[SouthEast]: /images/20220810/7378ed7f5b254d809cd360692757c454.png
[SouthEast 1]: /images/20220810/bcc119beb65943a5bbe9149b0bb0f9dc.png
[Center]: /images/20220810/c8999c7a30474816bf7c5a09b1ceb1a8.png
[SouthEast 2]: /images/20220810/ed9d96946c024ab4aa17ac0e277d9042.png
[SouthEast 3]: /images/20220810/ed097c26300a43e68aa671b57e4d20e6.png
[Link 2]: http://blog.csdn.net/u010924834/article/details/37995321