Blog

Dynamic applications through configuration

The scenario

 Imagine you have an application that connects to a CRM instance (this could be anything really, Sharepoint, Salesforce,..). Your application needs to get data from CRM, and in order to do that, it first needs to login.
Easy enough, you just create a method that connects to the datasource, hardcode the username, password and login link and you're all set. Why would any of those things ever change anyway? Passwords dont need to change. It's even better if they never do! 

How many times have you seen code like this? I hope not that much!

This might seem like a good idea in the beginning, and it might not even matter for a long time, but one day one of these things is inevitably going to change. And when they do, you're not going to want to dive into the code, change the data, recompile, and deploy again. It might seem like not that big of a deal to change this in the above example, but I think we all know how complex and terrifying (legacy) code can be.

Luckily there is a way to handle these kinds of situations. All applications, be it a website, console app, WCF,.. have a configuration file. This is an awesome place to configure stuff (that's probably also why they called it that way)

But how can we get data from the configuration file into our application? There are 2 ways to do that.

Custom ConfigSections

The first way we can handle this, is by specifying our own custom Section in the configSections of the configuration file. All we have to do is give it a decent name, and point it to the type and assembly. In this case the type is "CrmConfiguration", and the assembly is "Configuration".

 

In our custom configsection, we can define all the properties and keys we want. In the above example I have placed all the data that we previously hardcoded in the CrmConfiguration section.

The next thing we have to do, is create a class that will serve as a wrapper to fetch this information.

 

This is done in the above screenshot. All we do is basically create a public property for each of the keys we defined in the custom configuration section. This does not only make our application more dynamic, it also enables us to use strong typing.

We can now use the wrapper we created to login to the crmContext. As you can see in the screenshot below, all of the data is fetched from the configuration file.

 

 

Doesn't this look alot cleaner?

 

Regular AppSettings

The scenario above is actually a pretty good example of when you would want to create a custom configuration section. There are a decent amount of properties and it also makes the intent more clearer when just quickly looking through the config / code. It's possible though that you simply don't need to do something like this, and that all you want is a simple setting like "TestMode". If you're in a situation like this, there is also a way to create a dynamic and strong typed alternative to hardcoding stuff in code. Lets look at the example below:

We're still in the configuration file, but this time we did not define any custom configSections. All we did was add 2 keys to the AppSettings section, being TestMode and MailFrom. We can also create a wrapper class to fetch this data for us:

 

 

All we have to do is create a class with some public properties, and use the ConfigurationManager.AppSettings property to access they keys we need.

Below is an example of how you could use the wrapper class.

 

Conclusion

There are plenty of reason to use configuration files, the most important ones in my opinion are listed below:

  1. You can let an application continue to do its work, despite of some external changes (password, URL, ..) by simply editing the configuration file. No need to recompile / dive into code or deploy anything.
  2. The intent of your application will become much clearer. Having clearly defined sections/wrapper classes make it alot easier to get the big picture, than a bunch of inline strings spread across a codebase.
  3. You can change the entire runtime of your application (from instance from Test to Production) by simply changing a value in the .config file.

 

 

 

Technology Technology

Op 18/06/2014 door Maarten

blog comments powered by Disqus