如何将 Javascript 作为 HTML 代码存储在网站中
我将 Web 表单和 Asp.Net 与 MS SQL 一起使用。
对于我的网站，我需要存储这些代码，亲爱的，也许将来还有其他代码：
- Google 分析代码，
- 我的模板的一些 JavaScript 代码
- HTML 页脚和页眉。
我需要一个可以集中、使用缓存、易于更新的解决方案：
这里是我的想法，我想听听您的意见：
- 01 使用带有表（配置表）的数据库，该表对于每个记录（VARCHAR）将允许存储这些 spinets代码作为字符串。
- 02 在特定文件夹中使用简单的文本文件，这样我就可以将这些文件包含在我的代码中。我可以使用 FTP 和记事本更新代码（这里我担心缓存）。
- 03 使用Web.Conf 文件。
- 04 使用文本文件和一个类来管理在缓存中存储这些文件的内容。
有什么想法吗？感谢您抽出时间。
在这里，我想重点介绍该主题的有用文章：
I use Web Forms and Asp.Net with MS SQL.
For my Web Site I need store these codes belove, maybe others in future:
- Google Analytic Code
- Some JavaScript codes
- HTML Footer and Header for my template.
I need a solution which could be centralized, use CACHE, easy to update:
Here my ideas, I would like your opinion:
- 01 Use a DATABASE with a Table (configure table) which for every records (VARCHAR) would allow storing of these spinets of code as string.
- 02 Use simple Text Files in a specific folder, so I can include these files in my code. I could update codes using FTP and NotePad (Here I am concern about cache).
- 03 Use Web.Conf file.
- 04 Use Text File and a Class wich would manage storing in cache the content of these file.
Any ideas? Thanks for your time.
Here I would like highlight and useful article for this topic:
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
首先，关于 Nathanael Jones 博客的引用链接，尽管磁盘 IO 比内存操作慢得多，但大多数网站都不受磁盘 IO 限制，坦率地说，他的大多数解决方案都是没有受过教育的垃圾。
一般来说，只有极少数情况会受到 DISK io 限制。第一个是数据库服务器本身。如果没有足够的 RAM 来将数据库的相关部分保存在内存中，那么该服务器的磁盘速度就至关重要；尤其是在交易量较高的情况下。
其次，如果您的应用程序直接读取和写入大量文件，则可能会受到磁盘 IO 的限制。很少有应用程序这样做。我没有计算应用程序的 .aspx 或 .html 文件，因为这些文件可以由现有框架和 IIS 缓存。
基本上就是不理他。
整个文件系统到数据库同步的想法作为提高性能的方法对于大约 99.999% 的站点来说没有任何价值。如果不出意外，数据库应该将文件推送到 Web 服务器文件系统，而不是相反。在 20 年的开发过程中，我只见过 1 个站点需要这样做。他们每天提供数百万的页面浏览量。此外，他认为通过网络进行数据库调用比从本地文件加载同等数量的数据更快，这是完全错误的。
接下来，我们真正关注的实际领域是通过网络将数据发送到客户端浏览器。这总是比从磁盘读取文件慢；即使线路上没有流量。硬盘驱动器传输数据的速度比网卡快得多。更进一步；现代硬盘驱动器比互联网连接快几个数量级。为了提高性能，您可以做的最好的事情就是限制单个页面加载所需的连接请求数量。这里的优化是指有1个css文件，而不是20个；只有几个 .js 文件引用，而不是 100 个；并在可行的情况下将图形组合成精灵。由于 TCP 的工作原理，传输 1 个大文件比传输 100 个小文件更快。
也许在过载的共享服务器上您可能会遇到问题。然而，现实情况是，过载的共享服务器在磁盘队列长度增长失控之前很久就会出现网络拥塞。
解决这个问题后，让我们看看您的实际问题。
javascript 项目有两个首选位置： 1. 作为 Web 服务器上的 .js 文件或 2. 嵌入到母版页中。只需执行选项 1，它们就会被 Web 服务器缓存。此外，它们将由客户端浏览器缓存，这意味着您不必
为您的页眉和页脚，其代码应该位于您的母版页中。不要做服务器端包含，这只会让事情变得复杂。构建一个普通的 .net 网站，利用母版页来显示“chrome”内容。您可以在应用程序级别启用部分页面缓存，这将为您处理所有缓存。
当您更新页眉或页脚内容时，只需重新部署站点即可。
First off, regarding the referenced link to Nathanael Jones blog, although disk IO is much slower than in memory operations most websites are not disk IO bound, and most of his solutions are quite frankly uneducated crap.
Generally speaking there are only a very few situations in which you become DISK io bound. The first is the database server itself. If it doesn't have enough RAM to keep the relevant parts of the database in memory then disk speed of THAT server is crucial; especially in a high transaction situation.
Second, you can be disk IO bound if your application directly reads and writes a lot of files. Very very few apps do this. I'm not counting the .aspx or.html files of your application because those can be cached by the existing framework and IIS.
Basically, just ignore him.
The whole filesystem to database syncing idea as a method to improve performance is of no value to about 99.999% of sites. If nothing else the database should be pushing files to the web server file system, not the other way around. I have seen exactly 1 site in 20 years of development that required this. They serve several million page views a day. Also, he is flat wrong about making a database call across a network being faster than loading an equivalent amount of data from a local file.
Next, the actual area that we are really bound at is in sending data across the network to the client browser. This is ALWAYS slower than reading a file from a disk; even with no traffic on the line. Hard drives move data much faster than your network card can. Taking it one step further; modern hard drives are orders of magnitude faster than your internet connection. The best thing you can do to improve performance is just to limit the number of connection requests a single page load requires. Optimization here means having 1 css file, not 20; having just a couple .js file references, not 100; and combining graphics into sprites where feasible. It's faster to transfer 1 big file than 100 small files due to how TCP works.
Maybe on an overloaded shared server you might have an issue. However, the reality is that an overloaded shared server is going to be network congested long before it's disk queue length grows out of control.
With that out of the way, let's look at your actual issue.
The javascript items have two preferred locations: 1. As .js files on the web server or 2. embedded in your master page. Just do option 1, they will be cached by the web server. Further, they will be cached by the client browser meaning you won't have to
For your header and footer, the code for this should be in your master page. Don't do server side includes, that just complicates things. Build a normal .net website that leverages master pages for your "chrome" content. You can enable partial page caching at the application level which will handle all of caching for you.
When you update the header or footer content, just redeploy the site.
将页眉和页脚存储在文件中并使用服务器端包含。
某些 Web 服务器（IIS 6.0）可能允许您向所有页面添加文档页脚。
将 Javascript 存储在文件中并在页面中使用。这将允许缓存并提高页面性能。
Store your headers and footers in files and use Server Side Includes.
Some web servers(IIS 6.0) may allow you to add document footers to all the pages.
Store your Javascript in files and use the in your pages. This will allow caching and improve page performance.