Quelle est l'implémentation courante pour XSLT + .Net côté serveur?

Question

Quelle est la structure de classe commune pour l'utilisation de XSLT + .Net? (côté serveur XSLT) Mon but est d'éviter les webforms standards, qui tendent vers le MVC pur, tout en conservant toutes les opportunités d'ASP.net (mise en cache, gestion de session, etc.). Est-il préférable de l'implémenter en tant que gestionnaire, ou au niveau de la page, ou en tant que contrôle? Cela dépend-il absolument d'une tâche particulière ou encore il y a des implémentations préférables? Quelle est la mise en œuvre la plus flexible? Maintenant, je reçois une chaîne xml du domaine via Facade (entités de domaine implémentent IXMLSerializable), en chargeant et en mettant en cache une collection statique de XslCompiledTransforms du disque en tant que singleton, et un contrôleur (en tant que httphandler) qui règle la logique du traitement des demandes. a un accès aux classes précédentes et aux pages mises en cache. Est-ce correct?

Answer 1

Je fais du développement en utilisant un modèle centré XML et j'ai trouvé que l'approche du gestionnaire personnalisé fonctionne très bien pour le XML -> XSLT -> HTML. Veiller à ce que la couche d'accès aux données soit découplée est important pour que les gestionnaires restent concentrés sur leur tâche spécifique.

Vous mettez déjà en cache les XslCompiledTransforms, ce qui est génial, car la compilation initiale est le plus gros succès de certaines applications que j'ai écrites.

En termes de 'implémentations préférables' - vous ne trouverez pas beaucoup d'informations sur ce style de service HTML. Le manque de support de XSLT 2.0/XPATH 2.0 dans les bibliothèques de base et ne se concentrant pas sur ce type de développement de Microsoft sont les principaux contributeurs, IMO.