Meglio quindi XSLT o LINQ to XML Transformation?
Riprendo il mio post dell'altro giorno, per darvi un resoconto sui feedback che ho ricevuto (principalmente diretti e via email ... curioso) piuttosto che tramite commenti (siamo tutti un po' timidi evidentemente, ma non c'è nulla di male).
In sostanza tutte le persone che mi hanno risposto propendono per XSLT. Considerando che io adoro XSLT e consiglio di usarlo da diversi anni, posso esserne contento e dovrei ritenermi soddisfatto.
Ad onor del vero mi sembra però giusto segnalare i pro ed i contro più evidenti di entrambe le soluzioni che proponevo.
XSLT
- PRO:
- Possiamo scrivere trasformazioni che prescindono dall'ambiente di sviluppo: XSLT è "super-partes"
- Possiamo modificare le trasformazioni senza dover ricompilare nulla del codice delle nostre applicazioni che usano quegli XSLT
- Il codice è molto leggibile, perché descrive la struttura dell'output che vogliamo ottenere
- CONTRO:
- Il codice non viene compilato, se non con alcune piattaforma (tipo .NET 2.0) all'atto della prima esecuzione, ma a runtime, con evidenti rischi sulla stabilità degli applicativi
- Eventuali errori nel codice XSLT, che per molti non è poi così leggibile, non sono evidenziati e non sono bloccanti per la compilazione del progetto che usa l'XSLT stesso
- Non ci sono dati tipizzati (quanti di noi, usando XSLT 1.0, hanno desiderato funzioni per la gestione delle date o dei numeri?! Già ... magari ci fossero state nativamente!)
- Eventuali errori nella modifica estemporanea del codice XSLT, in fase di manutenzione, potrebbero bloccare l'esecuzione di un'applicazione che di per sé si compila ed è corretta
- Non possiamo svolgere unit testing sul codice XSLT con VSTS o altri tool
LINQ to XML Transformation
- PRO:
- Lavoriamo con un unico linguaggio all'interno di un unico ambiente di sviluppo: .NET
- Lavoriamo con variabili tipizzate e con tutte le class library di .NET a disposizione
- Il codice viene compilato e verificato in fase di compile-time e non di runtime
- Possiamo eseguire unit testing sul codice scritto
- CONTRO:
- Siamo vincolati a .NET (Ma questo per Microsoft :-) non è un problema ...)
- Il codice è meno leggibile, perché XML si legge meglio di C#, in particolare quando C# usa classi e oggetti nuovi (come quelli di LINQ to XML/XLinq)
- In caso di modifiche alla trasformazione dobbiamo ricompilare l'applicativo (o l'assembly di estensione che contiene il codice delle trasformazioni ...)
Forse allora possiamo giocarci un jolly ... e valutiamo il codice che vedevamo nel post precedente, scritto con LINQ to XML Transformation, ma utilizzando i nuovi XML Literals di Visual Basic 9, anziché il solo LINQ to XML, in un qualsiasi linguaggio .NET. Con VB9 infatti potremo scrivere nel codice VB degli "inserti" di XML che saranno convertiti per noi, dal compilare VB9, in codice LINQ to XML. In pratica il codice C# che vedevamo nell'altro post, e che a molti di voi non è (forse giustamente) piaciuto rispetto ad XSLT, in VB9 sarebbe una cosa tipo la seguente:
Dim destinationXmlCustomers As XElement = _
<c:customers xmlns:c="http://schemas.devleap.com/Customers">
<%= From c in sourceXmlCustomers.Elements("customer")
Where c.Attribute("country").Value = "Italy"
Select _
<c:customer xmlns:c="http://schemas.devleap.com/Customers">
<c:name><%= c.Name %></c:name>
<c:city><%= c.City %></c:city>
</c:customer> _
%>
</c:customers>
Dove questo "fritto misto" :-) di XML, VB9 e markup che ricordano ASP3/ASP.NET (<%= ... %>), consentono di scrivere codice XML (quindi visivamente chiaro), compilato a compile-time, verificabile con unit testing, tipizzato, che può sfruttare le class library di .NET, ma che trasmette anche l'idea di quello che sarà l'output XML desiderato, senza nemmeno i tag di XSLT che per molti sono ostici e fanno confusione. Ovviamente in caso di modifiche alla trasformazione questo codice dovrà essere ricompilato, però forse è anche giusto ricompilarlo ... dopo aver fatto unit-testing, piuttosto che provare se il nostro applicativo "gira ancora" dopo aver cambiato a mano un XSLT, magari con Notepad.
LINQ è ancora in beta (CTP di Gennaio 2007), quindi non sto dicendo cosa sia giusto o cosa sia sbagliato, anche perché è presto per tutti per dirlo (credo), però voglio stimolare la discussione su quello che sta arrivando ...