Producing Reports with .Net and Telerik
“Nothing can be said to be certain, except death, taxes, and having to write reports.”
No matter what kind of application you dream of creating, your boss will eventually and very heartlessly kill your dreams by asking you to waste your life programming some kind of report so that some suit somewhere can kill a rainforest with their limitless need to print pretty tables and charts and show them off to their manager friends.
Ah! I feel much better now that’s off my chest.
I’m no stranger to the world of reporting. One of my very first developer jobs was to create a report-generator for a bank. As everyone seems to do, we started off using Crystal Reports. I soon got sick of that, so I wrote one using Delphi and XML-FO (don’t ask!) . I’ve used many other tools, such as SQL Server Reporting Services (SSRS) and DataDynamics (now Grapecity) ActiveReports, but recently I found Telerik Reports to be quite a good option. And as I get so many lovely comments on my blog from DotNet newbies, I thought I’d write a quick review of it here and it just might help someone.
The 3 Principles of Good Reports
Every reporting tool needs to fulfill 3 requirements, based on the people you’ll have to make happy with your reports. For the corporate design people, you’ll need good design tools so that every positioned element can be pixel perfect (it won’t get past them otherwise). For the users, it needs to run fast and produce a document in their favourite formats – usually either Excel or PDF. (You’ll find that they generally prefer Excel so they can fudge the figures and pretend it was your tool which did it!). And for developers, it needs to be easy to program and fit well with your processes.
So how does Telerik Reporting do in all these areas?
Like most tools nowadays, Telerik Reports provides you with a designer which is integrated with Visual Studio, and a variety of controls to use on that designer (just like you do with Windows Forms). It comes with the standard TextBoxes, PictureBoxes, Shapes and Panels, which are all very important (don’t underestimate the need for something as simple as a line in a report).
Other reporting tools I’ve used came with a RichTextBox control for producing formatted text. I guess that Telerik thought that the Rich Text Format was out-of-date now though, because they give you an HtmlTextBox instead. In many ways that’s a good step, because the HTML they allow in that control has many more options for styling than Rich Text does, such as background colors, borders, and padding. I’ve managed to produce quite good looking documents with the HtmlTextBox.
Another benefit to this control is that you can let a user control what goes in it. You could, for example, allow a user to enter HTML in a Wysiwig control in a web form and load that HTML into the report itself. That would be great for dynamic creation of letters, for example.
On the downside, I’ve found that you don’t always need HTML-styling for a report, due to the lack of control in how the styling renders with fluid text, but I’m sure it has uses sometimes. I also miss the lack of a justified text option, which is a big problem if you want to use it for producing letters, as that’s how most letters are formatted.
A typical mistake when creating reports is that your output gets slightly cut-off due to margin errors. Telerik has a nice way of handling this by adding a warning sign to the designer to alert you to the potential problem before you waste all your energy walking back-and-forwards to the printer.
Like most other tools, Telerik has good support for Sections and Groups, which means you can easily apply headers, footers and subtitles to your pages. The flow of text between sections is also important, and Telerik does a good job there too.
There are plenty of other controls too, such as barcodes and checkboxes. And of course, at some point you’ll need to use charts, which Telerik has extremely good support for. Thinking about it, I suppose the charting tool is really one of the biggest reasons to consider Telerik Reports in the first place.
One of my biggest pet peeves with reporting tools is that they can often be too restrictive. Crystal Reports and SSRS, for example, were very closely tied to a particular kind of data source when I used them. That meant you frequently couldn’t use them with your own particular architecture, and you all-too-often had to rely on database queries to populate your report. While that might be good for some people, it was never right for me.
On the other hand, while it does have good integration with particular types of data source – such as SQL databases – Telerik Reports allows you to bind your reports to any kind of data. You can then write code-behind for the report which will do exactly what you want with the data at runtime. For me, that means I can keep all the view-logic separate from the data-logic, meaning I can utilise the same data for different “views” of the data, i.e. in a web page, a PDF document, or whatever else I choose. The data stays the same and the views of that data change around it.
Another benefit that brings is with testing. If you want to be able to test your reports, you’ll be at pains to have to run it against a database all the time. Using the approach of multiple views, you can mock out the data passed to the report and make sure it appears just right. You can even build it into your build server tests.
A nice feature I’ve seen with the latest version of Telerik Reports is an Entity Framework data-source. I haven’t used it yet, but I have used Entity Framework a lot, and I can see how it might be helpful. (Let me know what your experience is with it if you use this feature.)
Another plus-point for Telerik is the ability to control what data gets put into a control at runtime. You can use simple expressions to match up field contents, but you can also write complete functions in your code-behind which will be integrated into the report at runtime, giving you complete control of formatting – anything you can do in code can appear on your report. That also means you could supply XML, JSON or any other data format to the report and write code to get the exact data out which you need to display on your report.
Speaking of code-behind, I think that this feature is one of the best things Telerik Reports has to offer. For example, in one job it was important that I controlled the name of the file as it was created, which I wanted to do before sending it back to the client from a web page. Telerik lets you do that when you initialise the report in the code-behind, meaning I had full control of the naming at the time it was rendered. Splendid!
At the end of the day, what really matters is what you get out of your reporting tool, and how fast it does it. Telerik Reports is especially good in this area, as it produces such a wide variety of formats. The standards are there – PDFs and spreadsheets – with support for PDFs (version 7.0 and higher), and for both the old and new Excel formats. It also supports Word documents very well. And now it even has Powerpoint support - I’d better not tell that to the business guys or their tiny little heads might explode with excitement!
Another feature you might like is the report viewer, which allows you to embed your report in a Windows form, a WPF form, a Silverlight control or even a web page. I don’t use that feature very often, but I have used it once or twice to allow a user to see a report before they print or save it, and it seemed very competent. The output was produced in a second or two, and looked just like the printed output would have done.
Generally it isn’t an understatement to say that reporting tools aren’t always that great. In fact, they can be generally quite rubbish. But I must say, I’ve had some good success with Telerik Reports, and am not planning to use anything else any time soon.
I just hope they add support for justified text.
For more info, check the Telerik website: http://www.telerik.com/