5
votes

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?

6
When the connectionstring was born, OOP was not really available, I think :-)Rhapsody
You could have a bit of fun and make your own connection object class, whose ToString() would build the appropriate connection string using its properties.BoltClock
Legacy. But I suppose there's nothing stopping you from creating a connection string formatter class with properties.Vlad
@BoltClock, +Vlad: DbConnectionBuilder seems to do pretty much what you are describing. It's name/value pairs instead of predefined properties, though.Randy supports Monica
For provider connection strings you can use provider specific versions of DbConnectionBuilder. E.g. SqlConnectionBuilder exposes strongly typed properties of known SQL Server key/value pairs.Randy supports Monica

6 Answers

4
votes

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.

4
votes

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.

2
votes

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!

0
votes

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...)

0
votes

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.

0
votes

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.