Class design - Excel report
Although arguably a Pandora's box of other complications, have you considered ditching the Interop libraries and driving this through Ace/Jet drivers via OleDB?  Too often do I see well-intentioned applications fall over because Excel gets upgraded.  Best-case scenario you'll have to manage multiple releases, whereas oftentimes you're stuck redeveloping because of core changes that break existing methods.

Even when I need specific functions available only to the Interop libraries, I try to avoid using an actual reference in my project.  You can dynamically marshal your Excel.Application object if you're building this in .NET 4.0, and it gives you some flexibility depending on what you're trying to achieve.

If you're just interested about data transfer, I'd consider making a move to OleDB if you're comfortable with SQL-based database querying.

I think by omitting your specific methods of how the data gets into the sheet, you're leaving out one of the most important parts of the application in terms of performance.  Are you dumping the data cell by cell?  I'm assuming coming from SQL the data will be in DataSet/DataTable format, so you could dump to an array, and then point to an address in the sheet.

I do like that you've avoided the dreaded double-dot, and are taking the proper Marshalling release methods to make sure Excel goes away when it's supposed to.

/$.02

-- Locke