What to do when data becomes too large for web.config

Consider an ASP.NET MVC application which is dependent on configuration data which is not ideal for storage inside web.config.

This data is mostly freetext, such as document templates and markup which is loaded when the web application starts. It is considered unideal for web.config storage because it is quite large.

Thoughts on storage so far are:

• Stored in the database: Ideal scalability and protection from HTTP requests. However requires additional application code to manage the data.
• Stored on the file system: Ideal for s开发者_高级运维wappable files but sensitive to HTTP requests.

How have you solved this problem?

edit:

The answers provided so far are great, but let me elaborate on the conditions here so we can get closer to the solution. This is a web application which will be downloaded by interested persons and installed on their own web servers. These persons may wish to customize certain aspects of the application. The web.config file is ideal for many things: SMTP server settings, connection strings, and other nominal values.

However, the application also pulls from heavier configuration, such as a series of file templates - written in HTML and simple domain-specific markup. Some of these are somewhat large.

Storage in web.config

Storing this data in web.config will require some pretty weighty configuration elements. An element in my custom section might start to look like this:

<template key="..."><![CDATA[
    (very large text here)
]]></template>

I don't possess knowledge of a way of leveraging the 'InnerText' of a web.config ConfigurationElement in this manor. Maybe IConfigurationSectionHandler of olde.

Storage in the data store

SQL Server 2008 is being used along with Entity Framework 4. Writing a separate helper application, or including the controller and views to manage these configurations in the database doesn't really fit in with the design path of the application; this may be my own fault for not thinking of it earlier. Asking the user to correct these fields in Management Studio isn't an acceptable way to skip writing a UI either.

Storage on the file system

Placing the data in one or more files on the file system allows easy access on the host computer and more or less eliminates the need for a UI or Management Studio. However these files must not be accessible by HTTP request. Web.config enjoys protection by IIS, and similar protection would be required for these files.

Storage in a resource

I can't really offer any complaints with this approach. We will have to hash out whether recompiling the application to update the config is alright.

There is also another option - resources, this will give you build-in mechanism of data access, but will require recompilation of your app on every text change.

The best way to store such data will be database but if you don't want to connect db to your app - use files. File access will be managed on the webserver level quite easily, so it shouldn't be a problem.

You can create separate file and link it with web.config.

Here it shows how to link multiple files with web.config.

http://www.davidturvey.com/blog/index.php/2009/10/how-to-split-the-web-config-into-mutliple-files/

Look at the problem from the future prospect not from the current state.

If it is expected to expand AND you need to search in contents the best choice is database - it is created for it

If it won't and you just need to show it's contents to the users then file system is enough.

HTH

Ivo Stoykov