为什么我们需要连接字符串？

Question

当我们连接到ASP.NET中的数据库时，您必须指定适当的连接字符串。但是，要指定数据的大多数其他实例都是在对象中完成的。

例如，为什么我们不能拥有连接对象，例如：

var connection = new connectionObject(){
   DataSource = "myServerAddress",
   IntialCatalog = "myDataBase",
   UserId = "myUsername",
   Password = "myPassword"
}

远远好于一些键/值字符串：

  

Data Source = myServerAddress; Initial   目录= MYDATABASE;用户ID =名为myUsername;密码= MYPASSWORD;

我能想到的唯一原因是允许在web.config中存储，但是无论如何都没有什么能阻止我们将各个值存储在那里。

我确信有充分的理由，但它们是什么？

Answer 1

嗯，在上面的示例中，如果要更改连接的任何部分，则需要重新编译和部署。要解决这个问题，您需要在某处存储该信息（配置文件）。这几乎就是连接字符串允许你做的事情 - 有一个由配置驱动的连接。

Answer 2

遗产，传统，但最重要的是：灵活性。

尝试编写（或者只是想象）可以处理所有 MS-SQL，Oracle和（嵌套）ODBC配置的connectionConfig对象。而这只是支持.NET的几个数据库。

此外，这种对象的主要目的是以（某种程度上）人类可读的形式进行序列化。

因此，XML是一种替代方案，而固定（一组）对象则不是。

Answer 3

我确信这只是历史。连接字符串至少返回到ADODB，ADODB例如在经典Visual Basic中使用。这可以追溯到ODBC，这可能就是这个想法的来源。我们这里不是在谈论.NET。我们正在谈论一个具有完全不同的对象概念的世界（如果有的话）。因此，最简单的方法是使用DSL来指定连接。

为此使用对象可能会有点复杂，因为要为不同的数据库驱动程序指定不同的字段。只是说...

此外，由于这些字符串非常遗留，因此您可以期待您感兴趣的任何数据库都能理解这些字符串。轻松连接到您最喜欢的新数据库！

Answer 4

您可以创建一个包装器来构建连接字符串，就像您的示例中一样，但我怀疑您可以完全避免使用连接字符串。数据库期待一个连接字符串，这已经很长一段时间了。看到它们仍然是常态，可以安全地假设优点超过缺点。

Answer 5

连接字符串通常驻留在xml配置文件（Web.config）或注册表中。对它们进行硬编码是个坏主意。此外，它们应该是人类可编辑的。无论如何它都是文本。

（啊，还有一些特定于提供商的密钥，afaik ......）

Answer 6

主要原因是连接数据库所需的信息取决于数据库供应商。 Oracle以一种方式做事，旧的Jet引擎以不同的方式做事，SQL Server以另一种方式做事，ODBC规范......好吧，你得到了图片。

在MSDN中查看DbConnectionStringBuilder类及其子类，以获得创建连接字符串的强类型方法。