.NET中的Global vs Singleton

我这里有一个非常普遍的情况.多年来我还没有发现我所做的事情是否符合行业标准.考虑连接数据库的应用程序,但是连接字符串而不是存储在某个文件/设置中的是作为命令行参数传递的在启动时或者在应用程序启动时浏览数据库.

那么有必要将该连接字符串保存在应用程序范围内的某个位置.我看到它最常见的方法是使用get/set方法保存连接字符串的模块或全局类.我会这样做的另一种方法是使用Singleton.当需要通过GetConnectionString方法时,我的DAL可以访问连接字符串.

这样做有更好的方法吗？

更新:我没有配置文件,即使我这样做,我还需要在应用程序实例的生命周期内读取一次连接字符串.你能详细说明"把它注入任何课程"部分吗？

在一般情况下,无论是全局类还是单例,都应该尽可能避免.

理想的解决办法是让你的应用程序加载了连接字符串进行配置,并注入它到任何需要它的类.根据应用程序的大小,像Unity或Castle Windsor这样的IoC容器可以提供帮助,但肯定不是解决方案的必需部分.

如果这不是一个选项,并且你被维持全局状态(因为现有的代码库或其他),我不知道你建议的两种方法之间存在巨大差异.

更新:为了澄清,暂时忘记关于IoC容器的所有内容,"注入"只是一种说法"作为参数传入"(对于类的构造函数,或通过属性,或其他)的一种奇特方式.

而不是让数据访问类必须要求连接字符串(来自某种全局或单例),让它通过构造函数或属性传入.

更新#2:我认为这种方法的含义仍然存在一些误解.

它主要归结为您的数据访问类是否如下所示:

public class DataAccessClass
{
    public DataAccessClass()
    {
        _connString = SomeStaticThing.GetConnectionString();
    }
}

要么

public class DataAccessClass
{
    public DataAccessClass(string connString)
    {
        _connString = connString;
    }
}

这些 文章(事实上​​,该博客中的许多文章)详细说明了为什么后者比前者更好的原因(尤其是因为前者几乎不可能进行单元测试).

是的,在某个地方,首先必须要有一些静态的人负责抓取连接字符串,但关键是你对静态方法的依赖只限于那个地方(这可能是你的引导应用程序的主要方法),而不是遍布整个代码库.

很高兴看到这么多创意解决方案来解决这么简单的问题;-)

来自OP问题的显着事实:

connect-string在命令行上传递

许多其他组件可能需要使用connect-string

所以,没有办法使用静态元素 ; 它是一个全局变量(在.NET中很难做到,真的,没有封闭类),静态类或单例确实无关紧要.最短路径解决方案是由处理命令行的Program类初始化的静态类.

每个其他解决方案仍然需要静态访问传入的连接字符串,尽管它们可能隐藏在一个或多个间接层后面.

我不是说你不想用更高级的东西打扮基本解决方案,但这不是必要的,并且它并没有消除所描述的连接字符串的基本静态/全局性质.