what is common implementation for server-side XSLT + .Net?

Question

What are the common class structure for using XSLT + .Net? (server-side XSLT) My aim is to avoid standard webforms, tending to pure MVC, but still keep all the opportunities of ASP.net (caching, session management etc). Is it better to implement it as handler(s), or on Page level, or as Control? Does it absolutely depends on particular task or still there are preferrable implementations? What is most flexible implementation?

Now i get xml string from domain via Facade (domain entities implement IXMLSerializable), loading and caching a static collection of XslCompiledTransforms from disc as a Singleton, and a Controller (as a httphandler) who rules the logic of request processing and has an access to the previous classes and cached pages. Is that right?

Answer 1

I do development using a XML centric model and I've found the custom handler approach works just fine for serving XML -> XSLT -> HTML.

Making sure to keep the data access layer decoupled is important for keeping the handlers focused on their specific task.

Your're already caching the XslCompiledTransforms which is great because the initial compile is the biggest performance hit in some of the apps I've written.

In terms of the 'preferrable implementations' - you wont find a lot of information out there talking about this style of serving HTML. The lack of XSLT 2.0/XPATH 2.0 support in the core libraries and having no focus on this type of development from Microsoft are the main contributors, IMO.