从烟雾到土壤：关于我们泰北的生物炭项目的更新
对于大多数开发人员而言，第一次需要将PDF报表添加到内部应用程序时，会浪费一天时间。
他们尝试浏览器打印对话框。 输出看起来不对。 他们尝试客户端PDF库。 布局崩溃。 他们自己编写了一个带有定位文本和绝对坐标的东西。 它对一个报告有效，下一次就崩溃了。 当他们发布此功能时，已经花费了八小时来解决一个应该只需要二十分钟的问题。
Jeff Fritz向一屋子初学者展示如何在二十分钟内完成。
研讨会
如果您不知道Jeff Fritz：他是微软MVP、微软的首席项目经理，同时主持长期运行的Fritz and Friends流。 他为刚开始.NET旅程的开发人员提供免费研讨会，几周前他举办了一个最具野心的：五小时的现场构建，涵盖HTML、CSS、C#、Blazor、ASP.NET和.NET Aspire，整个团队从头开始构建一个工作中的收藏跟踪应用程序。
四小时后，应用程序需要PDF报告。 用户应该能够点击一个按钮并获得他们收藏的干净、可下载的PDF。 现实世界的内部工具。 每个产品经理最终都会要求的那种功能，每个开发人员最终必须发布的功能。
Jeff教的模式是大多数团队应该使用的，当您看到它时，它值得详细解说，因为您不会再选择错误的工具。
五步模式
它大致是这样的。 看似短小精悍。
为报告专门创建一个Razor页面。 Jeff在项目的Pages目录中创建Report.razor。 小选择，大回报，把报告作为自己的页面意味着它可以独立于其他UI进行样式调整、重新生成和测试。 报告成为应用程序的一个一流部分，而不是附加在另一个视图上的黑客。
注入数据上下文。 Entity Framework Core CollectionContext工厂通过依赖注入进来，就像应用程序中的每个其他数据获取点一样。 没有特殊模式，没有变通方法，没有单独的报告数据路径。 报告使用与应用程序其他部分相同的数据，以相同的方式。
将报告呈现为HTML。 这是区分优秀模式与脆弱模式的关键举措。 Jeff没有选择PDF专用的布局语言。 他将报告编写为HTML，与他整个下午使用的标记相同，并让现有的样式工作。 页眉、表格、部分，全是HTML。 最终输出是PDF的事实是后续的细节。
将HTML转换为PDF，只需一行。这是IronPDF赢得其地位的地方。 ChromePdfRenderer将HTML字符串转换为使用Chrome引擎进行正确渲染的真实PDF。 在浏览器中看起来正确的CSS在PDF中也看起来正确。 没有需要学习的单独样式层，也没有要调试的渲染怪癖。
- 将其作为文件返回。当用户点击按钮时，浏览器会干净地下载PDF。 完成。 功能发布。
这就是整个模式。 五个步骤，二十分钟的流时间，以及一个在生产中经得起考验的功能。
为什么这个方法有效
这个模式之所以正确的更深层原因是耐用性，但表面的原因是每个步骤都映射到开发人员已经知道如何做的事情。
编写报告布局？ 就是HTML和CSS，与其他页面相同。 查询数据？ 同样的EF Core模式。 将页面集成到应用程序中？同样的Razor页面，同样的DI。 唯一真正的新步骤是转换为PDF，而这仅需一行代码。
比较一下其他选择。 打印对话框方法在用户使用不同浏览器、不同缩放级别或意外的打印机设置时立即崩溃。 客户端PDF库迫使开发人员学习一种全新的布局语言。 手动滚动的基于坐标的布局对一个报告有效，但对第二个报告却无济于事。 这些方法都无法在真实产品中存活。
服务器端HTML到PDF模式则能存活。 输出是一致的、可预测的且中心化的，在每个客户端上，相同的输入每次都产生相同的PDF，因为渲染在一个地方根据一组规则进行。 对于内部工具、面向客户的报告、审计跟踪文档，任何输出一致性真正重要的地方，这都是一个经得起考验的模式。
这个研讨会之所以讲授它很清楚，是因为没有时间教其他方式。
尝试在您自己的项目中使用
用于转换步骤的库Jeff使用的是IronPDF, 免费试用，包含30天试用密钥。 用商业电子邮件注册，密钥将发送到您的收件箱，您可以在自己的项目中在下午结束前构建Jeff Fritz教授的模式。 试用期间没有水印，完整功能访问，所有API可用。
如果您推迟添加PDF报表，是因为上次尝试花了一天时间，那么这是一个耗时二十分钟的项目版本。
观看完整的研讨会
Jeff的完整课程可以在他的YouTube频道观看。 PDF报告部分从4:56:48开始，但前面的模块也值得一看，它们是现代.NET栈的清晰渐进，Jeff的教学确实非常好。
免费开始
免费开始
预定免费现场演示
