考虑一个ASP.NET MVC应用程序，它依赖于配置数据，这对于存储在web.config中的存储来说并不理想。当数据变得太大以至于web.config时该怎么办
该数据大部分是自由文本，例如Web应用程序启动时加载的文档模板和标记。对于web.config存储来说这被认为是不理想的，因为它非常大。在存储
思想至今都：
- 存储在数据库中：从HTTP请求理想的可扩展性和保护。但是需要额外的应用程序代码来管理数据。
- 存储在文件系统：适用于可交换文件，但对HTTP请求敏感。
你是怎么解决这个问题的？
编辑：
到目前为止提供的答案是伟大的，但让我阐述一下这里的条件，所以我们可以更接近的解决方案。这是一个Web应用程序，将由感兴趣的人下载并安装在他们自己的Web服务器上。这些人可能希望定制应用程序的某些方面。 web.config文件非常适用于许多事情：SMTP服务器设置，连接字符串和其他名义值。
但是，该应用程序也从较重的配置中拉出来，比如一系列文件模板 - 用HTML编写，以及简单的特定于域的标记。其中一些有些大。
存储在web.config中
存储在web.config中这个数据将需要一些相当有份量的配置元素。在我的自定义节的元素可能会开始看起来像这样：
<template key="..."><![CDATA[
(very large text here)
]]></template>
我不具备的撬动一个web.config的ConfigurationElement的“的innerText”在这个庄园的方式了解。也许是IConfigurationSectionHandler的老。
存储在数据存储
SQL Server 2008中正在随着实体框架4.写一个单独的辅助应用程序，或者包括控制器和视图的数据库来管理这些配置使用并没有真正的符合应用程序的设计路径;这可能是我自己的错，因为之前没有考虑过它。要求用户在Management Studio中更正这些字段并不是跳过编写UI的可接受方式。文件系统
将数据放置在一个或多个文件的文件系统上
存储允许主机计算机上轻松访问和或多或少消除了对用户界面或Management Studio中的需要。但是，这些文件不能通过HTTP请求访问。 Web.config受IIS保护，这些文件需要类似的保护。
存储在资源
我真的不能提供这种方法的任何投诉。我们将不得不重新编译应用程序以更新配置是否正常。
额外的应用程序代码来管理数据库中的配置数据可以很简单，SSMS可用于大部分是（或你的数据库服务器的等价物） –
我会出于一个简单的原因，可维护性，请去数据库。如果你的应用程序是一个关键的业务组件，那么很可能你需要冗余，并且最简单的方法是在网络端实现这一点，恕我直言，就是使用网络农场。这意味着您将拥有两台或更多台服务器，并且每次更改模板时都需要确保更新所有服务器。在数据库中配置这种配置有助于数据库更新，确保所有Web服务器只需一次更新即可看到新数据，如果操作正确，则无需停机。 –