Web Application Configuration Settings - Best Practice

Recently, I was involved in fixing a web application project and noticed the previous table of the developers database used for configuration options instead of web.config (app.settings).

What should i use? web.config or database table? What's better?

+4
source share
7 answers

The following should appear in web.config:

  • These are the things that must be available to make the database accessible (db connection string!)

  • These are things that, if they need to change, you want the application pool to be updated, or which, apparently, are unlikely to have changed.

  • These are things that should be available when the database is unavailable for any reason (for example, a list of email addresses and an smtp server for sending error messages or the locations where the log files are located)

The database should include the following situations:

  • Both your database and your web layer use this configuration.

  • You need to change the configuration on the fly, without forcing to update the application pool.

However, if you intend to host your configuration in a database, you will probably want to cache it somehow in the web layer so that you don't make unnecessary use of db. I suggest a Cache class for this.

In addition to all of the above, you will also need to consider your company's policy for working with your servers. If you are very, very difficult to work with db, it may make sense to invest in web.config and vice versa.

+7
source

One of the advantages of using a database for customization is that things can be changed on the fly without disrupting the creation of a website.

Changes to the web.config file will restart workflows in IIS, and the application will restart. If you use InProcess sessions, they will be lost. This can potentially damage the users of your website.

+2
source

We use a combination of web.config parameters and database level settings.

For each parameter, we ask the following question: "Is this parameter specific to the device in which the application is running?" If so, then it goes to web.config. If not, we ask an additional question: "If this parameter is changed, should the application be restarted?" If yes, web.config. Most often, rebooting is not suitable for our service level agreements.

Most of our applications are multi-user and / or running in a web farm. Simple things, such as the local file system path, logging level, or database connection strings, are in the web.config file. The reason is that they are dealing with resources specific to this machine.

Almost everything else will affect the execution of the program and should be available for both applications and data layers. In addition, they are usually needed by other applications (provided that several applications fall into the same database).

+2
source

It makes sense why before. dev used DB to configure, go with it. You should have web.config, I think ASP.NET cannot work without it. Project configuration settings should be included in web.config (declarations of user controls, additional assemblies, etc.), but user preferences or something specific in business logic may be better in the database.

+1
source

A controversial issue between developers and database administrators in my company.

In my opinion, you should always use configuration files for the application level, read-only. If the settings are user-defined or editable at runtime, you may or may not want to reconsider the approach.

I have seen situations where settings are stored in a database that are used inside stored procedures. I see some justifications for this, but this is not critical, since the value can be passed to the procedures through the parameter.

+1
source

One consideration may be that after deploying the web application, the developer no longer had access to the web.config files in the production environment.

If he sometimes needs to look at the settings to provide any form of support, placing the settings in a database, where he can read-only access to the configuration table, can make tons of sense.

+1
source

In one case, which claims that the database uses load-balanced applications, such as web farms. There may be some settings that relate to one machine that is different from other farm machines that should be sent to web.config, but there will probably be many settings that should be the same throughout the farm. It is assumed that the farm will look like one the application is external and can come in handy if it can be configured as a single machine. This means some kind of shared repository, such as a database.

0
source

All Articles