연기에서 토양으로: 북부 태국에서의 바이오차 프로젝트 최신 업데이트
대부분의 개발자는 내부 앱에 PDF 보고서를 추가하려고 처음 시도할 때 하루를 허비합니다.
그들은 브라우저 인쇄 다이얼로그를 시도합니다. 출력 화면이 잘못됩니다. 클라이언트 측 PDF 라이브러리를 시도합니다. 레이아웃이 깨집니다. 위치 지정 텍스트 및 절대 좌표를 사용하여 무언가를 직접 만듭니다. 한 보고서에는 작동하지만 다음에는 망가집니다. 기능을 발송할 때까지, 당초 20분이면 끝날 문제에 8시간을 소비합니다.
Jeff Fritz는 초보자들이 가득한 방에서 20분 안에 하는 방법을 보여주었습니다.
워크숍
Jeff Fritz를 모르셨다면: 그는 Microsoft MVP, Microsoft의 수석 프로그램 매니저이며, 오랫동안 운영된 Fritz와 Friends 스트리밍의 진행자입니다. 그는 .NET 여정 초기에 있는 개발자들을 위한 무료 워크숍을 운영하며, 몇 주 전에는 가장 야심찬 워크숍 중 하나를 운영했습니다: HTML, CSS, C#, Blazor, ASP.NET, .NET Aspire를 포함한 5시간 라이브 빌드를 진행하면서 그룹 전체가 처음부터 끝까지 작동하는 컬렉션 추적 애플리케이션을 구축했습니다.
4시간이 지난 후, 애플리케이션에는 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를 다운로드합니다. 완료되었습니다. 기능이 발송되었습니다.
전체 패턴이 그곳에 있습니다. 다섯 단계, 스트림 시간 20분, 그리고 프로덕션에서 견디는 기능.
왜 이게 작동하는가
더 깊이 있는 이유는 이 패턴이 내구성 있는 것이지만, 표면적인 이유는 모든 단계가 개발자가 이미 할 줄 아는 것과 매핑되기 때문입니다.
보고서 레이아웃 작성? HTML과 CSS, 다른 모든 페이지와 동일합니다. 데이터 쿼리? 동일한 EF Core 패턴. 페이지를 앱에 연결? 동일한 Razor 페이지, 동일한 DI. 유일하게 진정으로 새로운 단계는 PDF 변환이며, 이는 한 줄입니다.
대안을 비교하면? 프린트-다이얼로그 방식은 사용자가 다른 브라우저, 다른 확대 수준, 또는 예기치 못한 프린터 설정을 사용할 때 끊깁니다. 클라이언트 측 PDF 라이브러리는 개발자가 완전히 새로운 레이아웃 언어를 배우게 만듭니다. 손으로 생성된 좌표 기반 레이아웃은 한 보고서에는 작동하지만 두 번째에서 붕괴됩니다. 이러한 접근 방식 중 어느 것도 실제 제품과 접촉 후 생존하지 못합니다.
서버 측 HTML-to-PDF 패턴은 생존합니다. 출력은 일관되며 결정적이고 중앙 관리 되며, 동일한 입력이 모든 클라이언트에서, 매번 동일한 PDF를 생성하며, 렌더링이 한 장소에서 한 세트 규칙하에 이루어지기 때문입니다. 내부 도구, 고객 대면 보고서, 감사 추적 문서, 일관된 출력이 실제로 중요한 장소라면, 이 패턴이 견디는 것입니다.
이 워크숍은 다른 방식으로 가르칠 시간이 없기 때문에 이를 깔끔하게 가르칩니다.
자신의 프로젝트에서 시도해보세요
Jeff가 변환 단계에 사용하는 라이브러리, IronPDF는 30일 체험 키를 통해 무료로 시도해 볼 수 있습니다. 사업용 이메일로 등록하면 키가 받은 편지함으로 도착하며, 오후가 끝나기 전에 자신만의 프로젝트에서 Jeff Fritz가 가르치는 정확한 패턴을 구축할 수 있습니다. 체험판 동안 워터마크 없이, 전체 기능에 대한 접근 가능, 모든 API 이용 가능.
만약 PDF 보고서를 추가하려는 것을 미루고 있었다면, 과거 시도에서는 하루가 걸렸지만, 이 프로젝트 버전은 20분이 걸립니다.
전체 워크숍 시청하기
Jeff의 전체 세션은 그의 YouTube 채널에 있습니다. PDF 보고서 세그먼트는 4:56:48에 시작되지만, 이전 모듈도 시간이 충분한 가치가 있으며, 현대 .NET 스택을 통해 깨끗하게 상승하며, Jeff의 교육은 정말로 훌륭합니다.
무료로 시작하세요
무료로 시작하세요
무료 라이브 데모 예약하기
