I hate config files!

Skeeboe posted on Thursday, August 31, 2006

Here's what I'm thinking of doing. I'm thinking of modifying CSLA's DB function and have it read in a shared collection of db settings and other misc configurations. These setting, just like the configs change extremely rarely, if at all, once they are in the config

So I'd have one common config file that lists a connection string with one entry in it to the main db. Then the first time a DB function is called, CSLA would read from the config, get the sql connect string then get a collection of all other connection strings and settings from a table in the main SQL server. Then each successive DB read would return the its value from the shared collection.

I'm assuming that since its shared, all programs that would use CSLA would get the files from the shared collection.

This sounds good to me, in theory, but I'm not sure if it would even work. Then would it still work under  remoting?

Looking for your thoughts. Thanks.

pelinville replied on Friday, September 01, 2006

How do you get to the DB to get the config data in the first place?  Is the connection string to it hardcoded?

Skeeboe replied on Friday, September 01, 2006

I touched on that in the second paragraph above but I'll expand. The first time DB is called (i.e. the shared collection is empty) it will grab a connection string from a default.config file. That connection string will be the only thing in the file. It will use that connection string to connect to the database and grab all the other connection strings and other settings that each of my programs use. Then each successive call to DB would return the string or setting from the shared collection instead of reading from a config file.

P.S. I have already merged all the different DB calls to one common one and added an AppConfig method to CSLA that returns values from the config files that are not prefixed with 'DB:'.

figuerres replied on Friday, September 01, 2006

well a few things.

 

you might want to say "Only the first connection data" in the config file and not just think of the sql connection.

for example say I have a client that connects via web service ?

then I need a web server's address and a login for that.

for remoting you need to know where to connect.

also take a look at WCF and how it let's you switch connection / transport with a few simple changes.

also you may want to have some way to put a client certificate on a machine / install and use that to authenticate the user -- ssl / web service or whatever.

and use the config encyption stuff so that the details are not readable by users or tampered with.

also what about storing a config file on the server and sending that to the local machine?
I'm thinking of this as like a "caching" model:

if you do not have a config then go get one from the default source.

if you do have one then use it.

so that you are not moving mostly static data around everytime the app starts up.

you could store the whole file as an xml column in a table.

 

Vinodonly replied on Tuesday, September 05, 2006

 

i'm facing this same issue.. do u think using a access file or SQL Everywhere (currently in beta) is a good alternative, pls advs your comments.

RockfordLhotka replied on Tuesday, September 05, 2006

I did something along this line for a client a while back - but we were reading the actual data from an LDAP server instead of a database. Same idea though: a single entry in the config file, used to find the real data on a central server. It worked great, and was particularly nice for testing, because we had test and production LDAP servers and could aim the app at the right one by changing just that one line in the config file.

I would suggest that you not alter CSLA or use the DB() function for this purpose. Instead, I suggest that you create your own class (probably with Shared/static methods) that is used for this purpose. That way you not only avoid altering CSLA, but you end up with better seperation of concerns - having a class that is very clearly designed for this purpose.

In fact, in CSLA 2.0 I got rid of the DB() method, because .NET itself now has a much more powerful and extensible configuration system, and I saw no need for DB() to exist any further.