C# 模拟页面生命周期，从UI层获取html

我正在使用一个相当大的.net web应用程序

用户希望能够将报告导出为PDF格式。由于这些报告基于多个数据层的聚合，因此获得准确快照的最佳方法是实际拍摄UI的快照。我可以将UI的html解析为PDF文件

由于用户界面可能需要30秒才能加载，但结果永远不会改变，所以我希望在后台线程中保存项目后立即缓存pdf

我对这种方法的主要担忧是，如果我使用UI，我必须担心超时。虽然后台线程等可以持续任意长的时间，但aspx页面只能持续如此长的时间，直到它们被终止

我有两个办法来解决这个问题。第一个想法是创建一个aspx页面，用于加载UI、覆盖渲染并将渲染数据存储到数据库。后台线程将在内部向该页面发出WebRequest，然后从数据库中获取结果。这显然需要考虑到安全性，如果UI生成时间过长，还需要担心超时

另一个想法是创建一个页面对象并在代码中手动填充它，手动调用相关方法，然后从中获取数据。除了不知道如何做之外，该方法的问题是，我担心我可能会忘记调用一个方法，或者某些东西可能无法正常工作，因为它实际上与真正的会话或Web服务器没有关联

在后台线程中模拟页面UI的最佳方式是什么

如果“获取准确快照的最佳方法是实际拍摄UI快照”是真的，那么您需要重构代码

构建一个数据提供程序，向UI和PDF生成器提供聚合数据。分层您的系统

---

然后，当构建PDF时，您只有一个位置可供调用，并且没有黑客用户界面拦截/多线程问题可供处理。

我知道3种可能的解决方案：

处理程序 我有完整的答案。一般的jiste是通过实现自己的可读流和自定义的

IHttpHandler

来捕获

响应

这不允许您远程捕获页面的输出，但是，它只允许您捕获将事先发送到客户端的HTML，并且必须调用该页面。所以，如果你使用一个单独的页面来生成PDF，那么就必须称之为

网络客户端
使用ASP.NET实现这一点的唯一替代方法是使用阻塞
WebClient
请求生成HTML的页面。获取输出，然后将其转换为PDF格式。在你做所有这些之前，你可以检查你的缓存，看看它是否已经在那里了

WebClient client = new WebClient();
string result = client.DownloadString("http://localhost/yoursite");

WatiN（或其他浏览器自动化软件包）
另一个可能的解决方案是，它为您捕获浏览器的HTML提供了很大的灵活性。它的缺点是需要与桌面交互。下面是他们的例子：

using (IE ie = new IE("http://www.google.com"))
{
    ie.TextField(Find.ByName("q")).TypeText("WatiN");
    ie.Button(Find.ByName("btnG")).Click();

    Assert.IsTrue(ie.ContainsText("WatiN"));
}

+1，虽然目前这可能不是一个可行的解决方案，但至少需要努力。我们第一次进行了这个迭代。这变成了一场维护噩梦。最终，有人会在UI中创建特殊的逻辑，甚至像“如果项目来自法国，请以不同的方式显示表格，现在将此单元格涂成绿色，在此处更改拼写”这样的简单逻辑也不会反映在导出中，因为ascx和pdf输出都需要匹配，最终会导致不同步。这尤其适用于那些只想编辑ascx页面，甚至不考虑导出的人，因为这不是他们的工作。你要通过截屏来完成PDF的工作，因为你的开发人员缺乏必要的纪律？我同情你；这不是一个理想的情况。嗯。。。也许您应该考虑修改模型视图视图模型模式。基本上，为“自定义UI逻辑”添加另一层（ViewModel），并将这些决策放在那里。然后让您的ASPX和PDF渲染器绑定到该模型和逻辑。我仍然不知道如何创建一个视图模型，以取代ascx页面中对自定义代码的需求-我的意思是，让我们假设我更改了样式表？我怎样才能将该级联到每个PDF？ascx中继器之类的怎么样？那操纵DOM的javascript呢？@RickNZ:由于所需的工作量，它不在我的列表的顶部，但是如果你能想出一种方法来解决webrequest可能导致的超时问题以及在后台线程中生成页面可能导致的周期问题，我洗耳恭听。谢谢。Webrequest是我最初使用的解决方案。它在本地的一个盒子上完美地工作着。我对这些方法的关注是超时-如果服务器受到的攻击超出了合理范围，并且本地调用的aspx超时，那么可能会出现问题。显然，我可以使用某种计时器重试，但是如果用户现在想要，那就不是一个选项。