Web Development and Objects

Historically, the world of web development has been strongly resistant to the use of "stateful" objects behind web pages, and not without reason. In particular, using such objects without careful forethought can be very bad for website performance. Sometimes, however, it's suggested that instead of a stateful object, we should use a DataSet which itself is a very large, stateful object! Most people don't think twice about using one of those for web development.

Clearly then, stateful objects aren't inherently badit's how they're designed and how we use them that matters. Business objects can be very useful in web development; we just need to look carefully at how such objects are conceived and employed.

Note 

Objects can work very well in web development, if they're designed and used properly.

In Chapter 3, we discussed ADO.NET, including data reader and DataSet objects. As part of that discussion, we covered how web applications can choose from three basic data-access models as shown in Figure 9-1.

Figure 9-1: The three basic data-access models

Using the data reader directly can be very beneficial if our data set is relatively small and the page processing is fast because it allows us to take the data directly from the database and put it into our page. We don't need to copy the data into an in-memory container (such as a DataSet or business object) before putting it into the page output. This is illustrated in Figure 9-2.

Figure 9-2: Data flowing directly from a DataReader into a web form

However, if our data set is large or the page processing is slow, using a data reader becomes a less attractive option. Using one requires the database connection to remain open for longer, thereby causing an increase in the number of database connections required on the server overall, and thereby decreasing scalability.

Direct use of a data reader also typically leads to code that's harder to maintain. A data reader doesn't offer the ease of use of the DataSet or a business object. Nor does it provide any business logic or protection for the data, leaving it up to the UI code to provide all validation and other business processing.

Note 

In most cases, use of the DataSet or a business object will offer better scalability when compared to direct use of a data reader, and will result in code that's easier to maintain.

Having discounted the use of a data reader in all but a few situations, the question we're faced with is whether to use the DataSet or a business object as our stateful, in-memory data container. These options are similar in that the data is loaded from a data reader into the stateful object, and from there into the page, as illustrated in Figure 9-3.

Figure 9-3: Data is loaded into an intermediate object, followed by the web form.

This means that in general we can expect similar performance characteristics from DataSet s and business objects. However, our business objects are actually more lightweight than the ADO.NET DataSet object. This is because our objects are specific to the data they contain, and don't need to retain all the metadata required by the DataSet object.

Better yet, our business objects provide access not only to the application's data, but also to its business logic . As we discussed in Chapter 1, business objects can be thought of as smart data . They encapsulate the business logic and the data so that the UI doesn't need to worry about potential data misuse.

Overall, business objects provide the high-scalability characteristics of the DataSet , without the overhead. They offer a better use of database connections than the data reader, though at the cost of some performance in some situations. When compared to both other technologies, business objects enable a much higher level of reuse and easier long- term maintenance, making them the best choice overall.