Sunday, March 9, 2008

Coding vs. Configuration

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/coding_vs_configuration.htm]

Real-world applications need to be configurable. There are lots of reasons an app must be configured - different environment, modify the thresholds, even change what providers are used for a task. There's a big difference between coding, and configuration:

  • Coding implies writing the actual logic in some language (C#, VB, Java, Html, JavaScript, CSS, Sql, etc...). Coding, by its nature, can deal with complex logic, and may reside in many files across many directories. Sometimes code needs to be compiled into binaries. There's a lot of room for error here, which is why IDEs (like Visual Studio) provide code debugging, and why the community encourages unit tests and code reviews.

  • Configuration implies using knowledge of the domain to tweak the app, after it's been deployed, usually via a small number of config files.

 CodingConfiguration
Requires knowledge of language syntaxYes (and usually for many languages)No (syntax is usually just xml. A huge point of configs is that they abstract out syntax).
Requires business domain knowledgeYesYes
Requires re-compilingSometimes (C#, Java --> Yes, Html/Sql --> No)No. Usually just xml or plain text
Number of filesMany - a 10,000 line app, with 50 files, could still just have 1 app.configFew (usually just 1, or 1 per directory)

 

More and more, the push is to abstract coding into configuration. I believe WCF is big on this - instead of getting bogged down in how to transport data (web services, remoting, FTP, messaging, etc...) you just configure the app as appropriate. We also see this in domain specific languages and code generation. For example, .Net tiers has a big config file, but it makes perfect sense if you understand the concepts of N-Tier architecture. So, you can do a little configuration, and it generates 1000s of lines, which spares you from tons of tedious coding.

No comments:

Post a Comment