Du Fumée au Sol : Une mise à jour sur notre projet Biochar dans le nord de la Thaïlande

L'atelier

Si vous ne connaissez pas Jeff Fritz : c'est un Microsoft MVP, un Principal Program Manager chez Microsoft, et l'hôte du flux de longue date Fritz and Friends. Il organise des ateliers gratuits pour les développeurs qui débutent leur aventure .NET, et il y a quelques semaines, il en a dirigé un des plus ambitieux : une construction en direct de cinq heures couvrant HTML, CSS, C#, Blazor, ASP.NET et .NET Aspire, avec tout le groupe construisant une application de suivi de collection fonctionnelle à partir de zéro.

Quatre heures plus tard, l'application avait besoin de rapports PDF. Un utilisateur devrait pouvoir cliquer sur un bouton et obtenir un PDF propre et téléchargeable de leur collection. Une fonctionnalité d'outils internes du monde réel. Le genre de fonctionnalité que chaque chef de produit finit par demander et que chaque développeur finit par devoir livrer.

Le modèle que Jeff enseigne est celui que la plupart des équipes devraient utiliser, et cela vaut la peine de le décomposer parce qu'une fois que vous le voyez, vous arrêtez de vous tourner vers les mauvais outils.

Install IronPDF for Free

Le modèle en cinq étapes

Voici sa structure. C'est trompeusement court.

1. Une page Razor dédiée pour le rapport. Jeff crée Report.razor dans le répertoire Pages du projet. Petit choix, grand avantage, garder le rapport comme sa propre page signifie qu'il peut être stylisé, régénéré et testé indépendamment du reste de l'interface utilisateur. Le rapport devient une partie centrale de l'application, pas un bricolage ajouté à une autre vue.

2. Injecter le contexte de données. La fabrique CollectionContext de Entity Framework Core arrive par injection de dépendance, exactement comme tous les autres points de récupération de données dans l'application. Pas de modèle spécial, pas de solution de contournement, pas de chemin de données séparé juste pour les rapports. Le rapport utilise les mêmes données que le reste de l'application, de la même manière.

3. Afficher le rapport en HTML. C'est le mouvement qui distingue un bon modèle d'un modèle fragile. Jeff ne recourt pas à un langage de mise en page spécifique au PDF. Il rédige le rapport en HTML, le même balisage qu'il a utilisé toute l'après-midi, et laisse le style existant fonctionner. En-têtes, tableaux, sections, tout en HTML. Le fait que la sortie finale soit un PDF est un détail qui vient plus tard.

4. Convertir HTML en PDF avec une ligne. C'est là qu'IronPDF trouve sa place. ChromePdfRenderer prend la chaîne HTML et produit un vrai PDF correctement rendu en utilisant un moteur Chrome sous le capot. Le CSS qui a l'air bien dans le navigateur a l'air bien dans le PDF. Pas de couche de style séparée à apprendre, pas de bizarreries de rendu à déboguer.

5. Le retourner en tant que fichier. Le navigateur télécharge le PDF proprement lorsque l'utilisateur clique sur le bouton. Fini. Fonction livrée.

C'est tout le modèle. Cinq étapes, vingt minutes de temps de flux, et une fonctionnalité qui tient en production.

Pourquoi ça fonctionne

La raison profonde pour laquelle ce modèle est le bon est la durabilité, mais la raison superficielle est que chaque étape correspond à quelque chose que le développeur sait déjà faire.

Écrire la mise en page du rapport ? C'est du HTML et CSS, comme toute autre page. Interroger les données ? Même modèle EF Core. Connecter la page dans l'application ? Même pages Razor, même DI. La seule véritable nouvelle étape est la conversion en PDF, et c'est une ligne.

Comparez cela aux alternatives. Les approches de boîte de dialogue d'impression échouent dès qu'un utilisateur a un navigateur différent, un niveau de zoom différent, ou un paramètre d'imprimante inattendu. Les bibliothèques PDF côté client obligent le développeur à apprendre un langage de mise en page entièrement nouveau. La mise en page basée sur les coordonnées bricolée fonctionne pour un rapport et s'effondre sur le second. Aucune de ces approches ne survit au contact avec un vrai produit.

Le modèle HTML-to-PDF côté serveur survit. La sortie est cohérente, déterministe et centralisée, la même entrée produit le même PDF à chaque fois, sur chaque client, car le rendu se fait en un seul endroit sous un seul ensemble de règles. Pour les outils internes, les rapports destinés aux clients, les documents de traçabilité, là où la cohérence de sortie est vraiment importante, c'est le modèle qui tient la route.

Cet atelier l'enseigne clairement car il n'a pas le temps de l'enseigner autrement.

Essayez-le dans votre propre projet

La bibliothèque que Jeff utilise pour l'étape de conversion, IronPDF, est gratuite à essayer avec une clé d'essai de 30 jours. Inscrivez-vous avec un e-mail professionnel, la clé arrive dans votre boîte de réception, et vous pouvez construire exactement le modèle que Jeff Fritz enseigne dans votre propre projet avant la fin de l'après-midi. Pas de filigranes pendant l'essai, accès complet aux fonctionnalités, toutes les API disponibles.

Si vous avez repoussé l'ajout de rapports PDF parce que la dernière fois que vous avez essayé, cela a pris une journée, c'est la version du projet qui prend vingt minutes.

Commencez votre essai gratuit de IronPDF

Regardez l'atelier complet

La session complète de Jeff est sur sa chaîne YouTube. Le segment sur les rapports PDF commence à 4:56:48, mais les modules précédents valent aussi votre temps, c'est une montée en puissance propre à travers la pile .NET moderne, et l'enseignement de Jeff est vraiment bon.

Watch on YouTube