Skip to content
mythz edited this page Mar 18, 2013 · 2 revisions

Despite being avid protesters in the anti-XML config movement, we're still 100% for app Config in general though it should be limited to what's actually configurable by your application. Instead of building tiered configSection manatees we prefer to store structured data in Web.config's appSetting's values which are still able to express rich object config graphs but does so in a much more human-friendly and manageable size.

ServiceStack's Configuration API

To this end we provide our own pluggable Configuration API to provide high-level utility methods to read your Web.config's <appSetting/> values into a List, Dictionary or your own Custom POCO Type using the human friendly JSV format.

Benefits over XML Config

Benefits over existing XML Configuration APIs include:

  • The ability to store rich data structures in appSettings values
  • Much easier and requires less effort and boilerplate to create
  • Provides more succinct access to typed data
  • Since they're just POCOs can be re-used in all of ServiceStack's libraries and built-in Auto Mapping

and promotes less-coupling since its only an interface so can easily be swapped to have Plugins source their complex configuration from an different source (e.g. from a central DB) without a rewrite.

OpenId providers like the FacebookAuthProvider is an example of Plugins that require multiple configuration settings but remain de-coupled from any one configuration source (e.g. Web.config).

Example AppSettings Usage

By default ServiceStack ships with an AppSettings which reads from your Web.Config <appSettings/> and a DictionarySettings provider which can be populated with a standard C# Dictionary<string,string>.

Here's a quick example show-casing how to use the popular *AppSettings:

<appSettings>
<add key="LastUpdated" value="01/01/2012 12:00:00" />
<add key="AllowedUsers" value="Tom,Mick,Harry" />
<add key="RedisConfig" value="{Host:localhost,Port:6379,Database:1,Timeout:10000}" />
</appSettings>
var appSettings = new AppSettings();

DateTime lastUpdate = appSettings.Get<DateTime>("LastUpdated");
IList<string> allowedUsers = appSettings.GetList("AllowedUsers");

var redisConf = appSettings.Get<RedisConfig>("RedisConf");

//use default value if no config exists
var searchUrl = appSettings.Get("SearchUrl", "http://www.google.com");

Default configuration in code

The default value support is nice as it allows having workable default options in code whilst still remaining overridable in the Web.config when it needs to. This allows local and test projects to work without duplicating and maintaining and their own Web.config files whilst allowing arbitrary settings to be overridable in different deployment environments.

It also allows distributing Stand-alone Console applications like the PocoPower demo but still provide the opportunity to override the settings without recompiling the source, e.g:

var appSettings = new AppSettings();
var config = appSettings.Get("my.config", 
    new Config { GitHubName = "mythz", TwitterName = "ServiceStack" });

var github = new GithubGateway();
var repos = github.GetAllUserAndOrgsReposFor(config.GitHubName);

var twitter = new TwitterGateway();
var tweets = twitter.GetTimeline(config.TwitterName);

Easy to implement

Despite being so versatile, it's surprisingly easy to implement a new Configuration Provider, e.g. Here's the entire implementation for DictionarySettings which just needs to implement ISettings as is able to re-use the built-in AppSettingsBase base class:

public class DictionarySettings : AppSettingsBase, ISettings
{
    private readonly Dictionary<string, string> map;

    public DictionarySettings(Dictionary<string, string> map=null)
    {
        this.map = map ?? new Dictionary<string, string>();
        settings = this;
    }

    public string Get(string key)
    {
        string value;
        return map.TryGetValue(key, out value) ? value : null;
    }
}


  1. Getting Started
    1. Create your first webservice
    2. Your first webservice explained
    3. ServiceStack's new API Design
    4. Designing a REST-ful service with ServiceStack
    5. Example Projects Overview
  2. Reference
    1. Order of Operations
    2. The IoC container
    3. Metadata page
    4. Rest, SOAP & default endpoints
    5. SOAP support
    6. Routing
    7. Service return types
    8. Customize HTTP Responses
    9. Plugins
    10. Validation
    11. Error Handling
    12. Security
  3. Clients
    1. Overview
    2. C# client
    3. Silverlight client
    4. JavaScript client
    5. Dart Client
    6. MQ Clients
  4. Formats
    1. Overview
    2. JSON/JSV and XML
    3. ServiceStack's new HTML5 Report Format
    4. ServiceStack's new CSV Format
    5. MessagePack Format
    6. ProtoBuf Format
  5. View Engines 4. Razor & Markdown Razor
    1. Markdown Razor
  6. Hosts
    1. IIS
    2. Self-hosting
    3. Mono
  7. Advanced
    1. Configuration options
    2. Access HTTP specific features in services
    3. Logging
    4. Serialization/deserialization
    5. Request/response filters
    6. Filter attributes
    7. Concurrency Model
    8. Built-in caching options
    9. Built-in profiling
    10. Messaging and Redis
    11. Form Hijacking Prevention
    12. Auto-Mapping
    13. HTTP Utils
    14. Virtual File System
    15. Config API
    16. Physical Project Structure
    17. Modularizing Services
  8. Plugins
    1. Sessions
    2. Authentication/authorization
    3. Request logger
    4. Swagger API
  9. Tests
    1. Testing
    2. HowTo write unit/integration tests
  10. Other Languages
    1. FSharp
    2. VB.NET
  11. Use Cases
    1. Single Page Apps
    2. Azure
    3. Logging
    4. Bundling and Minification
    5. NHibernate
  12. Performance
    1. Real world performance
  13. How To
    1. Sending stream to ServiceStack
    2. Setting UserAgent in ServiceStack JsonServiceClient
    3. ServiceStack adding to allowed file extensions
    4. Default web service page how to
  14. Future
    1. Roadmap
Clone this wiki locally