我的ASP.NET Web应用程序中有很多XSL文件.很多.我使用这种通用转换方法生成一堆
AJAX
HTML响应：
public void Transform(XmlDocument xml,string xslPath)
{
...
XslTransform myXslTrans = new XslTransform();
myXslTrans.Load(xslPath);
myXslTrans.Transform(xml,null,HttpContext.Current.Response.Output);
}
我想使用xml类型的列将XSL定义移动到sql Server中.
我将整个XSL文件存储在sql中的单行中,并且每个XSL都是自包含的(无导入).我会将sql中的XSL定义读出到我的XslTransform对象中.
像这样的东西：
public void Transform(XmlDocument xml,string xslKey)
{
...
sqlCommand cmd = new sqlCommand("GetXslDefinition");
cmd.AddParameter("@xslKey",sqlDbType.VarChar).Value = xslKey;
// where the result set has a single column of XSL: "<xslt:stylesheet>..."
...
sqlDataReader dr = cmd.ExecuteReader();
if(dr.Read()) {
sqlXml xsl = dr.GetsqlXml(0);
XslTransform myXslTrans = new XslTransform();
myXslTrans.Load(xsl.CreateReader());
myXslTrans.Transform(xml,HttpContext.Current.Response.Output);
}
}
这似乎是一种直截了当的方式：
>为每个XSL添加元数据,如lastUsed,useCount等.
>批量更新/搜索功能
>防止大量磁盘访问
>避免引用相对路径和组织文件
>允许XSL更改而无需重新部署(我甚至可以编写一个管理页面来选择/更新数据库中的XSL)
有没有人试过这个？有什么警告吗？
编辑
响应者列出的注意事项：
>磁盘访问不能保证减少
>这会打破xsl：includes
解决方法
我能看到的两大问题是：
>我们使用了很多包含来确保我们只执行一次,将XSLT存储在数据库中会阻止我们这样做.
>它使更新XSL更有趣 – 我们非常乐意将新的.xsl文件转储到已部署的站点,而无需对站点进行全面更新.就此而言,我们有一些代码可以在文件夹中查找客户端特定的xsl,而这些代码可以回溯到根目录中的公共代码(模板) – 所以我不确定重新部署的东西是什么,但这在很大程度上取决于具体的用例,你的肯定与我们的不同.
在磁盘访问方面,嗯…数据库仍然必须访问磁盘来提取数据,如果你正在谈论缓存,那么数据库不是启用缓存的必要条件.
必须同意更新/搜索选项 – 您可以使用Powershell进行操作但需要在服务器上运行,这并不总是一个好主意.
从技术上讲,我没有理由不这样做(除了希望做的包括如上所述),但实际上它似乎与任何方式的良好论据相当平衡.
