De Fumaça a Solo: Uma Atualização sobre Nosso Projeto de Biochar no Norte da Tailândia
A maioria dos desenvolvedores, na primeira vez que têm que adicionar relatórios em PDF a um aplicativo interno, perde um dia.
Eles tentam o diálogo de impressão do navegador. A saída parece errada. Eles tentam uma biblioteca de PDF do lado do cliente. O layout quebra. Eles fazem algo manualmente com texto posicionado e coordenadas absolutas. Funciona para um relatório e despenca para o próximo. Quando lançam o recurso, já queimaram oito horas em um problema que deveria ter levado vinte minutos.
Jeff Fritz mostrou a uma sala cheia de iniciantes como fazer isso em vinte minutos.
O workshop
Se você não conhece Jeff Fritz: ele é um Microsoft MVP, Gerente de Programas Principal na Microsoft e anfitrião da longa série Fritz e Friends. Ele realiza workshops gratuitos para desenvolvedores que estão no início de sua jornada .NET, e algumas semanas atrás ele realizou um dos mais ambiciosos: uma construção ao vivo de cinco horas abrangendo HTML, CSS, C#, Blazor, ASP.NET e .NET Aspire, com todo o grupo construindo um aplicativo de acompanhamento de coleção do zero.
Quatro horas depois, o aplicativo precisava de relatórios em PDF. Um usuário deve ser capaz de clicar em um botão e obter um PDF limpo e baixável de sua coleção. Coisas reais de ferramentas internas. O tipo de recurso que todo gerente de produto eventualmente pede e todo desenvolvedor eventualmente tem que entregar.
O padrão que Jeff ensina é o que a maioria dos times deveria estar usando, e vale a pena explorar porque uma vez que você o vê, você para de alcançar as ferramentas erradas.
O padrão de cinco etapas
Aqui está a forma dele. É enganadoramente curto.
-
Uma página Razor dedicada para o relatório. Jeff cria Report.razor dentro do diretório de páginas do projeto. Pequena escolha, grande retorno, manter o relatório como sua própria página significa que ele pode ser estilizado, regenerado e testado independentemente do resto da UI. O relatório se torna uma parte de primeira classe do aplicativo, não uma gambiarra anexada a outra visão.
-
Injete o contexto de dados. A fábrica CollectionContext do Entity Framework Core entra através da injeção de dependência, exatamente como todos os outros pontos de recuperação de dados no aplicativo. Sem padrão especial, sem solução alternativa, sem caminho de dados separado apenas para relatórios. O relatório usa os mesmos dados que o restante do aplicativo usa, da mesma maneira.
-
Renderize o relatório como HTML. Este é o movimento que separa um bom padrão de um quebradiço. Jeff não busca uma linguagem de layout específica para PDF. Ele escreve o relatório como HTML, a mesma marcação que ele tem usado a tarde toda e permite que o estilo existente funcione. Cabeçalhos, tabelas, seções, tudo em HTML. O fato de que a saída final é um PDF é um detalhe que vem depois.
-
Converta HTML para PDF com uma linha. É aqui que o IronPDF ganha seu lugar. ChromePdfRenderer pega a string HTML e produz um verdadeiro PDF corretamente renderizado usando um mecanismo Chrome em sua estrutura. CSS que parece certo no navegador parece certo no PDF. Nenhuma camada de estilo separada para aprender, nenhum capricho de renderização para depurar.
- Retorne como um arquivo. O navegador baixa o PDF limpo quando o usuário clica no botão. Feito. Recurso lançado.
Esse é o padrão inteiro. Cinco etapas, vinte minutos de tempo de streaming e um recurso que se sustenta em produção.
Por que isso funciona
A razão mais profunda pela qual esse padrão é o certo é a durabilidade, mas a razão de superfície é que cada etapa mapeia para algo que o desenvolvedor já sabe fazer.
Escrevendo o layout do relatório? Isso é HTML e CSS, o mesmo que qualquer outra página. Consultando os dados? Mesmo padrão EF Core. Integrando a página no aplicativo? Mesmas páginas Razor, mesma DI. A única etapa genuinamente nova é a conversão para PDF, e isso é uma linha.
Compare isso com as alternativas. As abordagens de diálogo de impressão quebram no momento em que um usuário tem um navegador diferente, um nível de zoom diferente ou uma configuração de impressora inesperada. Bibliotecas de PDF do lado do cliente forçam o desenvolvedor a aprender uma linguagem de layout completamente nova. O layout baseado em coordenadas feitas à mão funciona para um relatório e colapsa no segundo. Nenhuma dessas abordagens sobrevive ao contato com um produto real.
O padrão HTML para PDF no lado do servidor sobrevive. A saída é consistente, determinística e centralizada, a mesma entrada produz o mesmo PDF todas as vezes, em todos os clientes, porque a renderização acontece em um lugar, sob um conjunto de regras. Para ferramentas internas, relatórios voltados para o cliente, documentos de trilha de auditoria, em qualquer lugar onde a consistência da saída realmente importa, esse é o padrão que se sustenta.
Este workshop ensina isso de forma limpa porque não há tempo para ensinar de outra maneira.
Tente no seu próprio projeto
A biblioteca que Jeff usa para a etapa de conversão, IronPDF, é gratuita para experimentar com uma chave de teste de 30 dias. Registre-se com um e-mail comercial, a chave chegará na sua caixa de entrada, e você pode construir o mesmo padrão que Jeff Fritz ensina no seu próprio projeto antes que a tarde acabe. Sem marcas d'água durante o teste, acesso completo aos recursos, todas as APIs disponíveis.
Se você adiou adicionar relatórios em PDF porque da última vez que tentou levou um dia, esta é a versão do projeto que leva vinte minutos.
Assista ao workshop completo
A sessão completa de Jeff está em seu canal do YouTube. O segmento de relatórios em PDF começa às 4:56:48, mas os módulos anteriores valem a pena também, são uma introdução limpa pela moderna stack .NET, e o ensino de Jeff é genuinamente bom.
Comece GRATUITAMENTE
Comece GRATUITAMENTE
Agende uma demonstração ao vivo gratuita
