Sintetizzo da subito quello che penso dei prodotti di reportistica attuali: “Una cag*ta pazzesca ” :-D, del resto lo penso da tempo immemore…
In questo senso l’accoppiata xaml/flow document/xps potrebbe avere un futuro notevole se nasceranno strumenti/designer e se verranno colmate alcune lacune non indifferenti, come ad esempio la mancanza del supporto per header e footer.
Guardando la mia esperienza di questi anni e osservando quello che vedo fare agli altri ho spesso la sensazione che ci si approcci al mondo reportistica in maniera totalmente errata e mi permetto di dire che anche gli strumenti che abbiamo a disposizione (aka designers) tendono a portarci fuori strada.
…potrei cominciare a pensare che il “designer visuale” è il vero male altro che il DataSet :-D
Un report è una view e come tale va trattato, ritengo penalizzante (e pure profondamente sbagliato) cercare di inserire logica all’interno del processo di rendering di un report, è un po’ come mettere logia nel processo di rendering di una view passiva in un modello MVP.
Il problema è che sempre più spesso mi capita di vedere che i designer dei report vengono utilizzati per creare, ad esempio, le join da cui poi scaturiscono i gruppi/breaking point all’interno del report, questo porta da un lato ad una penalizzazione delle performance e dall’altro ad una complessità di gestione assurda perchè quando ci vengono chiesti report un po’ strani, ed i clienti sono bravissimi a chiedere cose strane, facciamo i salti mortali all’interno del report.
La soluzione è decisamente sotto gli occhi di tutti ed è semplicemente quella di preparare dei DTO, siano essi dei dto veri e propri, un dataset costruito ad hoc o una view sul db, che siano pensati solo ed esclusivamente per la reportististica e che siano quindi “piatti”, e ad esempio read-only, e lascino al report il solo onere di fare le operazioni di grouping.
Nel mio caso sto utilizzando i Reporting Services (sia rdl che rdlc) e mi trovo molto bene con i DataSet che vengono egregiamente digeriti dal designer di Visual Studio, quello che faccio è quindi modellare dei DataSet, generalmente con una sola DataTable (se vi ritrovate costretti ad usare più di una DataTable finirete con l’ìutilizzare i subreport e direi che potremmo classificarlo come uno smell), che vengono “fillati” a runtime, in questo caso stiamo parlando quindi di report client (rdlc), utilizzando un adapter che è in grado di trasformare un grafo di oggetti di business nella sua rappresentazione per la reportistica.
Una cosa del tipo:
class ReportManager where T : IDomainEntity
{
   readonly IDataAdapter adapter;
   public ReportManager( IDataAdapter adapter )
   {
      this.adapter = adapter;
   }

   public void ShowReport( T entity )
   {
      var rptData = this.adapter.Adapt( entity );

      // … show the report …
   }
}
Sarà l’adaper che è in grado di scrorrere l’intero grafo e “trasformarlo” in una DataTable con quello che serve per il report.
.m