这一章几乎是纯理论的东西，自己不太擅长，所以就完全翻译了一篇文章。我们都知道图片操作是一种很费时的操作，如果一个网站是以图表为基础的话那么渲染方式就可以很大程度上影响网站的速度，即使是不以图表为基础的网站，有时不同的渲染方法安全性也不同。当然并没有什么完美的方法，只能从自己网站的实际情况出发来决定用什么样渲染方式。只有深入了解各种渲染方式的优劣才能做出更好的选择。
先解释一下这一章写什么吧，并不是说怎么渲染让图片更好看一些，而是讲如何生成图片，保存图片发送图片让我们的网站（如果是单机应用程序那么这一章的意义就不太大了，那时不会有多用户竞争访问和安全问题）更有效率也更加安全，好下面就是正文了，主要是翻译完全来的内容，原文是Using Microsoft's Chart Controls In An ASP.NET Application: Rendering the Chart。
一、生成图片并静态存储
渲染图片最简单直接的方法就是生成图片并将图片存储在服务器上，然后再显示出来。具体的过程为：当用户请求图表时，Chart控件在服务器上生成图片并将图片存储在服务器的特定目录下。然后Chart控件再生成一个<img>元素，并将<img>的src属性设置为刚才生成的图片。
静态存储图片时最重要的两个属性是：ImageLocation和ImageStorageMode。如果想要静态存储图片则ImageStorageMode设置为UseImageLocation，ImageLocation设置为存储图片的路径和图片名（但要注意不需要有图片的扩展名，扩展名可以用ImageType来指定），下面的代码段为一个简单的示例：
这样就会在服务器中的Images文件夹下生成Chart.png这个图片（注意用户对这个特定位置的权限问题），并呈现到网页中，但是这并不是完美的，主要有以下几个问题：
名字冲突问题：如果用以上的代码段两个用户访问网站时就会生成同样名字的两张图片，这样的问题如何解决。
如何辨别当前用户：如果两个用户同时访问同一个页面，如果这个页面中的图表是固定不变的，那不会有什么问题（呵呵，一般不会出现这种问题，如果都不变那就用一张静态图片就好了，用这个控件那么麻烦干嘛。。。）。但是通常情况下我们会根据不同的用户和用户的不同的选择生成不同的图片，那么问题就出现了。设想一下，如果第一个用户首先请求，Chart控件给他生成了一张图片，但还没有发送之前第二个用户又发出请求，也生成一张图片。两张图片会不会出现覆盖问题（就是第二张产生的时候把第一张删除了），如果不会如何来分辨这两个用哪个呢？
存储问题：如果真的和上面那样每次生成的图片都是一样的，服务器中只有一张图片，那不会出现存储问题，但上面的两个问题的出现我想大家也可能想到那就是要从文件名上下功夫，如果那样每一个访问这个页面都会产生一张新的图片，一直存储下去服务器的硬盘空间肯定是有问题的，如何来删除不用的图片呢？
我想有很多人也想到了解决这个问题就要从文件名上下功夫，只要每一个用户所产生的文件名不同，那么各自用户产生并使用自己的图片就好了。用户当然可以自己来用类似于随机数的方法来使每一个用户产生的文件名不同，但是微软给我们提供更加简单的方法。可用的关键字列表如下：
| 关键字 | 功能描述 |
| #UID | #UID会产生一个全局唯一标志符（globally unique identifier）这个标志符就会保证你生成的字符中唯一的（根据名字，这个很可能是全球唯一的，呵呵）。例如：如果设置ImageLocation为"~/Images/Chart_#UID"将会产生如 ~/Images/Chart_7795fa87-ef6b-4e9f-9c66-abb2b9980185.png这样的文件名，这可以保证文件名唯一（但是这样的话要注意文件存储的问题，设定删除图片的条件）。 |
| #SEQ(max,minutes) | 这个关键字可以生成一个从1开始直到max的序列，minutes表示某个元素再生成时的最少间隔（例如如果minutes设为2则表示在2分钟内不能生成重复的数字）。例如设置ImageLocation为 "~/Images/Chart_#SEQ(50,5)"时将会生成图上名如： ~/Images/Chart_000001.png. 下一个名称为： ~/Images/Chart_000002.png,直到 ~/Images/Chart_000050.png. |
| #NOGUIDPARAM | 为了加速显示，浏览器会缓存一些东西，例如如果两次请求两张名称相同的图片（在用#SEQ()时可能会出现这种情况）浏览器就会默认使用上一次已经接收到的图片，这时就可能会显示错误的图片，为了解决这个问题，通常的做法是在图片的后面加一个唯一的查询字符串，生成类似于~/Images/Chart_000002.png?7795fa87-ef6b-4e9f-9c66-abb2b9980185这样的图片地址，就不会重复了。 如果用这个选项就会阻止使用这样的方法使每次都从服务器请求图片。 |
呵呵，现在我们就可以把ImageLocation设置为~/Images/TempChartImages/Chart_#SEQ(25,2)这样不仅能保证每一次请求的地址都不同，还能让图片的张数不超过25张（如果服务器的用户很多可以将max设置为更大，时间也可以设置的短一些，当然在不会出现问题的情况下）。
二、用ChartHttpHandler来动态生成图表
用上面的方法将图片存储在大家网络用户可以访问到的地方如果对保密性很高的应用就会显得不怎么安全，所以就出现了将数据放到一些网络用户无法访问到的地方的解决方案。放到用户无法访问到的地方但用户还必须访问到其中的某些资源，所以就需要一个中介，这个中介就是ChartHttpHandler。ASP.NET用户可能对HttpHandler并不陌生。是的，ChartHttpHandler就是Chart控件自己的HttpHandler。在web.config文件中可以找到以下的代码段：
就是这个了。用户无法访问到的地方通常是指文件系统，内存和Session中，并且存放的地方是可以配制的，web.config文件中有类似于以下的代码段：
这一段代码表示将图片存储在内存中（storage=memory）并且在图片一使用完后就释放内存（deleteAfterServicing=true）。
这一段表示将图片存储在文件系统中，目录为c:/TempImageFiles/，20分钟超时。
这些都设置好了之后我们就可以使用ChartHttpHandler来动态生成图表了，我们可以什么都不设置，因为这些都是默认的，要设置的话只要把ImageStorageMode设置为UseHttpHandler就可以了。最后会生成类似于以下代码的图片：
<img src="ChartImg.axd?i=chart_1c564444b4a743489506139f3d9b5ce4_2.png&g=0deaa777d76843ac98e9c2bd05aee6db" ... />
至于为什么src设置成ChartImg.axd以及具体是如何处理的去查一下有关HttpHandler的资料我想并不难理解。
三、从Chart控件直接取得数据
上面的两种方法都是先让Chart控件生成图片，存储在一定位置后再发送给用户。我们也可以让Chart控件直接生成图片，并将2进制数据流直接发送到我们的页面。
使用2进制数据流的方法首先我们要生成一个单独的页面来产生2进制数据流，这个页面只能一唯一的一个Chart控件（也不能有其他的控件）。我们先假设这个页面为BStreaming.aspx，那么我们在要用这个图表的时候只要用<img src=”~/BStreaming.aspx”/>就可以了。
在生成BStreaming.aspx页面时可以用以下的格式：
注意两点：1、页面中不能有其他的元素。2、要将RenderType设置成BinaryStreaming。这样就可以了。
四、技术选择
在默认情况下是使用ChartHttpHandler并用以下配制：
但这个选项并不是在所有的情况下都是最好的，下面是三种技术的比较：
| 技术类型 | 优点 | 缺点 |
| 直接生成图片 | 容易设置和理解 容易控制文件路径和名称 | 不安全：用户可以通过改变图片的路径来获得其他用户的图表 增加硬盘读写，影响效率 需要要配制文件夹的读写权限 |
| ChartHttpHandler | 可以锁定图片，只让生成该图片的用户对这个图片有访问权限（需要配制ChartImageHandler的 privateImages属性） 可以通过将图片放在内存中来减少硬盘读写 具有配制图片存储位置的能力 | 在web.config中配制，超出了件本身属性的范围 每一样配制是针对整个网站，无法不同的图片存放在不同的位置 |
| 2进制数据流 | 直接发送数据，避免了“成/等待/发送”模式 可以用后台代码进行详细的权限控制 | 代码量大 不支持AJAX等交互方式 |
结论：呵呵，无非是根据自己的实际情况选用方式罢了，不多说了。
1711
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
