CODEWITHSUNDEEP
.netweb-config
weenoid
weenoid

Reputation: 1186

Storing values in code rather than web.config

I've recently started working on quite a large application and I've noticed that a lot of settings are stored in static classes/properties rather than in the web.config:

public static class FormSettings
{
    public const string HttpPostContentType = "application/x-www-form-urlencoded";
    public const string HttpPostMethodValue = "POST";
}

The only reason I can see for doing this is due to the large number of settings which would make storing them in a single file unwieldy.

Other than the fact these settings can't be altered without recompiling the code, are there any other disadvantages to this approach?

Edit:

Ok the example above wasn't the best:

public static class ThirdPartyApiSettings
{
    public const string EmployeeXmlNodeName = "Employee";
    public const string FirstNameXmlNodeName = "FirstName";
}

Upvotes: 0

Views: 145

Answers (2)

Sebastian Siek
Sebastian Siek

Reputation: 2075

Storing settings really depends on the application and scenario. With your approach, the biggest problem is that everything is hardcoded. As someone mentioned above, you have to think about :

  • how often the "variable" will be used
  • how likely is it to be changed
  • which part of application needs to access this variable
  • what information (settings) you going to store

There are few ways of storing settings :

  • Web.config (appsettings) - would not recommend this approach to store a massive list of settings (although it's just a collection of name-value). Also you can't really store complex types there (well...you can, but I've never seen anyone serializing objects and saving into web.config). This way is good for storing string values. The biggest problem (at least for me) with this approach is recompiling app everytime you add/change something in web.config.
  • Resource files - this is great for content - especially if you want to localize it. You could also store settings there. Problem with that - it's compiled and you can't easily update it.
  • Custom classes - good for storing costs and enums (which wont change very often), but it's not the best approach if you want to store content which is likely to change.
  • Custom XML files - I really like this approach as it allows you to change it withouth recompiling app - problem with that is that you have to write your own parser and be very carefull - it's very easy to missformat xml file :)
  • Database - localizable, remote, accessible by different applications, easy to change

You might also want to think if you need versioning, auditing and stuff like that.

Hope it helps.

Upvotes: 2

dwalldorf
dwalldorf

Reputation: 1379

You have more to compile, you have more dependencies and you can't change them without rebuilding the whole application.

Also, it's just not a programming part and should be seperated. You could also put your controller, view, action and dao in one file (in a webapp) and it would work but you just don't do that :)

Upvotes: 0

Related Questions