为什么我们需要连接字符串？
当我们连接到 ASP.NET 中的数据库时，必须指定适当的连接字符串。然而，大多数其他需要指定数据的实例是在对象内完成的。
例如，为什么我们不能拥有连接对象，例如：
var connection = new connectionObject(){
DataSource = "myServerAddress",
IntialCatalog = "myDataBase",
UserId = "myUsername",
Password = "myPassword"
}
这比某些键/值字符串要好得多：
数据源=myServerAddress;初始 目录=myDataBase;UserId=myUsername;Password=myPassword;
我能想到的唯一原因是允许在 web.config 中存储，但无论如何都没有什么可以阻止我们将各个值存储在那里。
我确信有充分的理由，但它们是什么？
When we connect to a database in ASP.NET you must specify the appropriate connection string. However most other instances where data is to be specified is done within an object.
For example why couldn't we have connection objects such as:
var connection = new connectionObject(){
DataSource = "myServerAddress",
IntialCatalog = "myDataBase",
UserId = "myUsername",
Password = "myPassword"
}
which is far better than some key/value string:
Data Source=myServerAddress;Initial
Catalog=myDataBase;UserId=myUsername;Password=myPassword;
The only reason I can think of is to allow storage in web.config, but there would be nothing stopping us storing the individual values in there anyway.
I'm sure there are good reasons, but what are they?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
遗产、传统，但最重要的是：灵活性。
尝试编写（或想象）可以处理所有 MS-SQL、Oracle 和（嵌套）ODBC 配置的connectionConfig 对象。这只是支持 .NET 的少数数据库。
此外，此类对象的主要目的是以（某种程度上）人类可读的形式进行序列化。
因此 XML 是一种替代方案，而固定（一组）对象则不是。
Legacy, tradition but above all : flexibility.
Try to write (or just imagine) the connectionConfig object that could handle all the MS-SQL, Oracle and (nested) ODBC configurations. And that's only a few of the databases supporting .NET.
Also, the main purpose of such an object would be to be serialized in a (somewhat) human-readable form.
So XML is an alternative, a fixed (set of) objects is not.
好吧，在上面的示例中，如果您想更改连接的任何部分，则需要重新编译和部署。为了解决这个问题，您需要将该信息存储在某个地方（配置文件）。这几乎就是连接字符串可以让您做的事情 - 拥有一个由配置驱动的连接。
Well, in your above example, you would need to recompile and deploy if you wanted to change any part of your connection. To get around that, you would need to store that information somewhere (config file). That's pretty much what the connection string lets you do - have a connection that is driven by configuration.
我确信这只是历史。连接字符串至少可以追溯到 ADODB，它曾在经典 Visual Basic 中使用过。这可以追溯到 ODBC，这可能就是这个想法的来源。我们这里讨论的不是.NET。我们正在谈论一个有着截然不同的物体概念（如果有的话）的世界。所以看来最简单的事情就是使用 DSL 来指定连接。
为此使用对象可能会有点复杂，因为需要为不同的数据库驱动程序指定不同的字段。只是说...
此外，由于这些字符串非常古老，因此您可以期望任何您感兴趣的数据库能够理解这些字符串。轻松连接到您最喜欢的新数据库！
I'm sure it is just history. Connection strings go at least back to ADODB, which was used for instance in classic Visual Basic. And that traced back to ODBC, which is probably where this idea came from. We are not talking .NET here. We are talking a world with wildly different notions of objects if any. So it seems the easiest thing to do was a DSL for specifying connections.
Using objects for this might get a little complicated, since there are different fields to specify for different database drivers. Just saying...
Also, since these strings are so very legacy, you can expect any database you are interested in to understand these strings. Easy to hook up to your new favorite database!
连接字符串通常驻留在 xml 配置文件 (Web.config) 或注册表中。对它们进行硬编码不是一个好主意。此外，它们应该是人类可编辑的。所以无论如何它都是文本。
（啊，还有一些提供商特定的密钥，afaik...）
Connection strings usually reside in xml configuration files (Web.config) or registry. It's a bad idea to hardcode them. Also, they should be human-editable. So it's text anyway.
(Ah, also there're some provider-specific keys, afaik...)
您可以创建一个包装器来构建连接字符串，如您的示例所示，但我怀疑您是否可以完全避免使用连接字符串。数据库需要一个连接字符串，这已经成为很长一段时间的常态。鉴于它们仍然是常态，可以肯定地认为利大于弊。
You could create a wrapper to build a connection string like in your example, but I doubt you can avoid using a connection string altogether. The database is expecting a connection string, and that's been the norm for a quite a while. Seeing as how they're still the norm it's safe to assume that the pros outweigh the cons.
主要原因是连接数据库所需的信息取决于数据库供应商。 Oracle 以一种方式做事，旧的 Jet 引擎以不同的方式做事，SQL Server 以另一种方式做事，ODBC 规范......好吧，你明白了。
查看 DbConnectionStringBuilder 类及其MSDN 中的子类用于创建连接字符串的强类型方式。
The main reason is because the information needed to connect to a database depends on the database vendor. Oracle does things one way, the old Jet engine does things a different way, SQL Server does things yet another way, the ODBC specs ... well, you get the picture.
Take a look at the DbConnectionStringBuilder class and its subclasses in MSDN for a strongly typed way of creating connection strings.