What s Not to Like?

What's Not to Like?

For most developers, report generation and batch processing are the two least enjoyable parts of any application. Much of this dislike stems from the fact that they're both rather complex to implement. Our development tools and the .NET platform itself provide powerful support for the creation of rich user interfaces and OLTP processing. Unfortunately, they offer comparatively little support for report generation or the development of batch-processing systems.

Tip  

Some versions of Visual Studio .NET ship with a version of the Crystal Reports report design tool. As we'll discuss later, this tool doesn't work against objects, which limits its value to us in many cases.

The complexity is amplified if we have developed our application to run in a distributed environment. This is because both report generation and batch processing interact with large amounts of data. The simple act of moving large amounts of data from the database server across the network to a web server or a client workstation can cause huge performance problems in our application. And yet to generate a report or perform a batch process, we need to interact with large amounts of data.

The fact that we're basing our application on the use of business objects can also increase complexity. When we code a batch-processing job, we're usually very careful only to retrieve the very minimum amount of data we need. Then we're very careful to optimize any data updates to minimize the impact on the database. We have to be very careful, because we're often interacting with thousands and thousands of rows of data, so retrieval of even one extra field can radically decrease performance.

Contrast this to a typical business object that's designed to support user interaction in an OLTP setting. In that case, we often retrieve extra data because we don't know what the user might want to see. We simply retrieve everything that the user might want, because it's cheaper to get all the data at once than to go back to the database over and over to get more data.

The use of business objects is also problematic in terms of report generation. This is because the commercial report-generation products on the market aren't designed to generate reports based on objects. Rather, they're designed to directly interact with a database in order to retrieve their data.

In this chapter, we'll discuss some of the key issues surrounding reporting and batch processing. Then we'll create some tools that can simplify our development efforts. In some cases, these tools may provide the answer to reporting or batch processing when creating distributed, object-oriented applications. In other cases, these tools may provide the base on which a more comprehensive solution can be built. Specifically, we'll be creating the following:

• A simple, server-based batch-processing engine

• A converter to generate a DataSet from an object or a collection of objects

The batch-processing engine is quite complex, even though it's a relatively simple implementation of the concept. The object-to- DataSet converter is a relatively straightforward application of reflection and ADO.NET code. I'm assuming by this point in the book that you've become quite comfortable with .NET technologies such as remoting, serialization of objects, and reflection, so we'll make use of them without a great deal of discussion. The batch-queue processor will also be multithreaded, so we're assuming some basic knowledge of threads and how they work too.