Help refactor legacy custom reporting module

Question

I have intranet win.forms (click once) application with custom built-in reporting module (40+ WinWord & Excel reports). Module is in separated assembly and abstracted via interfaces. We have sources and continue to support it.

Common interfaces look like:

IReportProvider {
  // introspection stuff 
  IEnumerable<ReportCategoryInfo> GetReportGroups();
  IEnumerable<ReportInfo> GetReports(Guid categoryId);
  ...

  // common function 
  ReportResult CreateReport(Guid reportId, ReportParamCollection prms, ..)
}

ReportInfo describes basic info & parameters required. UI is auto generated to let user choose report parameters.

class ReportInfo {
  public Guid Id { get; set; }
  public string Title { get; set; }
  public List<ReportParameterInfo> Params { get; set; }
  ...
}

and ReportResult provides binary report representation as well as binary type (is it Word2003, Excel2003, e.t.c)

class ReportResult {
  public byte[] Document { get; set; }
  public ReportType DocumentType { get; set; }
  public List<string> Warnings { get; set; }
  ...
}

There is no authentication requirements and word/excel representation is the must. PDF is not welcomed.

Problem is - every time report is added/corrected we update reporting module and publish new application version ('cos they are tied together).

I want to:

• avoid new application versions when reports are updated.
• We also have to add intranet web interface to reporting.

I am going to refactor present code the following way:

• Extract reporting functionality into separate WCF service
• Put report template files (excel & word templates) out of application and put to folder accessible to reporting service only.
• New WCF service will provide introspection interfaces (what reports are present and what parameters are required) and method to retrieve binary report representation (word or excel)
• There should be two clients that communicate with WCF service: Win.Forms for present client and Web one. Client will provide reporting navigation UI-interface to let user fill parameters and receive report file back. Win.Forms client will execute WinWord or Excel to show report received.

What do you think of that?

Answer 1

First of all: intranet win.forms? Are you talking about a ClickOnce WinForms application, an MSIE hosted WinForms application, a WinForms with an embedded web browser, or something even more exotic? I'm going to assume that you actually have a central data store, since otherwise your intranet web interface won't be happening...

This really depends on the interfaces to your WCF services (or whatever way you choose to host and interface your service logic). You haven't really described them. Some questions to ponder:

1. Is it a purely data based service, or does it do some user interface processing? The more of the latter, the worse support for Office and web reports simulatenuously... at one extreme, you're going to have to have two versions of each report. And then what happens when you want to add e.g. separate web versions for mobile interfaces?
2. How well can you decouple reports from services? Can the same services support several reports?
3. Are the data interfaces chunky or chatty? Chunky interfaces tend to scale better, but you pay the price with simple queries (since you need to pass more data than most reports need).
4. Do you have user authentication and authorization requirements? Are there reports or data which only some users are allowed to see?
5. Is WinWord and Excel a requirement or legacy? Do users really need editable documents: if not, would the web interface suffice, or a service providing PDF files? Generally speaking, Office integration isn't always the most easily supported option, especially once the next Office version or service pack hits you, or end users start tinkering with their templates...

What worries me somewhat is that you let the WCF service know about and even handle the report template files (template directory, introspection interfaces). Why? Wouldn't it be cleaner to have the templates depend only on a data retrieval service? Won't you have that relation with the web reports anyway?