In designing .NETOOP we have this issue:
Since .NETOOP will be an adaptable application designed to meet the needs of many users, some of the things that one might hard code in an application like “Web Site Name” will need to be set at installation time.
For “system” configuration settings we have the web.config file.
For language and culture variations we have resource files.
But this type of site configuration doesn’t really fit nicely into either of these categories.
We could use…….
- web.config
- .res files
- .xml files
- a table in the database.
There are a number of considerations.
- Since these are not really the same kind of configurations issues that we normally put in the web.config file (like a connection string) it would seem that web.config is not the right place for them and it’s a good thing to minimize the number of times someone edits the web.config file. Even if we created web UI for editing these settings folks will hand edit it. It might grow large and I don’t even know you you can store MCBS strings in the web.config.
- We could use resource files and create/edit them via System.Resources, but these file would not be “hand editable”.
- .xml files are easy to edit but in an environment where the database and the web server run on different machines, I/O from a database will probably be faster. (Especially in lower end shared hosting environments.)
- We could use a hybrid approach when edits are made in an XML file and imported into a database.
- We could address performance issues by using one of the many ASP.NET caching facilities and storing some commonly used items in application state (like site title.)
Please take the poll at http://twtpoll.com/st6sa4.
I’m hoping to do some coding on this issue TONIGHT !
THANKS !
Technorati Tags: Microsoft,ASP.NETOOP,.NETOOP
Filed under:
.NET
We have the same issue using a common web application codebase for multiple companies. We abstracted all of the high level site information into a SQL table and then cached the table values in the application. It has worked very well for us and is easy to change via an admin page on the site that updates the SQL table and refreshes the cache upon changes. We store everything that differs between sites such as administration email, technical support phone numbers, email server credentials, site title, etc.
How about using Windows Azure? Cloud computing appears to be the future and while they’re still in development, you can lead the way by showing how to create a real world application here.
I have been faced with issues like these before. But from a technical point and with all the technologies available today, i would prefer to use SQL table for site configuration that will change often and also to support medium trust in some environments. These will make it easy for the admin to change such settings and will make life easier for the developer and can also last over a long period
Hey, please, reactivate my account.
silentkiller007@live.com
or
silentkiller007@hotmail.com
Please, reactivate my account. It has some valuable files.
Reason : My dad was an army person. Before 4 months some bad people killed him. And we got upset. And i wasn’t able to use net for a long time. And now i can’t use my live account anymore. Seems its deactivated already for not use.
Please activate this and help me please.
RE: .NETOOP high level configuration storage decision.
Pingback from News .NETOOP high level configuration storage decision. | Web 2.0 Designer
we can split the web.config using "EnterpriseLibrary.ConfigurationSource (FileConfigurationSource)" and custom ConfigurationSection class for storing the application level settings.
Im not sure I have the experience to make a decision like this but after doing a little research Im inclined to use the caching combination not only for performance, but it would be a good tutorial for some of us unexperienced users (I still cant consider myself a "developer" yet)
RE: .NETOOP high level configuration storage decision.
Pingback from Dew Drop – June 25, 2009 | Alvin Ashcraft’s Morning Dew
I have stuggled with this decision many times. As of now, I am of the following mindset for all but extemely performance sensitive applications (which means none of our applications). (1). All connection strings should be in the root web.config of the target web site or web service. (2). All globalization values should be in res files. (3). All other configuration settings should be in the database and should be editable at run-time, for flexibility, maintainabilty, extensibility, etc– and, while this seems costly (a database grab for every setting read) it is a negligible cost in my experience and it makes the application WAY easier to manage. As such, the <appSettings> node should almost never be used. This may seem strange (it did to me) but it does work nicely. IMHO. HTH. Thank you. — Mark Kamoski.