.NET Patterns, Part II
- Stream-Based Programming
- Dispose and Finalize
- Asynchronous Programming
- Summary
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
In the previous article, I looked at some of the most important design guidelines that developers should use when writing code in .NET. These centered on naming conventions and standards for using framework features such as constructors and overloaded methods. In addition to these lower-level guidelines, the classes that Microsoft has written that comprise the .NET Framework feature a core set of design patterns that developers will need to be familiar with and emulate in their own code. In this article, I'll take a look at the streams pattern, the dispose pattern, and the asynchronous programming pattern. Keep in mind that these patterns and more are documented in the online documentation that ships with VS .NET under the class library design guidelines topic.
Stream-Based Programming
One of the most prevalent programming models that you'll find in the .NET Framework is the concept of streams. Simply put, a stream provides the means to read bytes from and write bytes to a backing store. A backing store is any persistent or nonpersistent storage where you want the bytes to end up. Not surprisingly, stream-based programming is implemented by providing a base class marked as MustInherit in VB .NET and abstract in C# called Stream in the System.IO namespace.
The Stream class provides the methods and properties to perform the fundamental operations such as Read, Write, Seek, CanRead, CanWrite, CanSeek, Length, Position, Close, and Flush. In this way, for example, a client can add bytes at a specific position in the Stream using Seek followed by Write, and can then Flush any buffered data to the backing store before continuing and eventually calling Close to release any resources such as file handles or sockets associated with the Stream. Streams also support the asynchronous programming model discussed later in this article.
The framework then contains multiple classes that are derived from Stream to work with particular backing stores, as shown in Table 1.
Table 1 Classes Derived from System.IO.Stream in the .NET Framework
|
Class |
Description |
|
System.IO.BufferedStream |
Used to buffer data when reading and writing to another stream. Acts as a layer on another stream. |
|
System.Net.Sockets.NetworkStream |
Used to send and receive data through network sockets. |
|
System.IO.MemoryStream |
Used to create a stream that has memory as a backing store rather than the network or a disk. |
|
System.IO.FileStream |
Used to read and write files on the file system in addition to pipes and standard input and output. |
|
System.Security.Cryptography.CryptoStream |
Used to perform cryptographic transformations of a stream using a particular cryptographic algorithm. |
Just as the .NET Framework implements classes derived from Stream, you can create your own derived Stream classes or even one of its descendants, such as FileStream, to encapsulate access to any backing store. For example, you could derive a Stream class to write to a proprietary file format in a particular location, thereby freeing the user of the class from having to learn both the file format and the particulars of where the data is stored. As a bonus, if you derive from Stream, you only need to override the synchronous Read and Write methods, and the base class implementation of the asynchronous methods will work automatically.
Of course, the interesting aspect of this architecture is that where a stream is called for in a method throughout the framework, any of the derived Stream classes can be used polymorphically. This allows different-backing stores such as a file or the network to be handled in exactly the same way. As a result, you'll notice that methods in the framework such as the WriteXml method of the DataSet class are often overloaded to accept a simple Stream object; at runtime, this can be any of the derived Stream classes. This allows the WriteXml method to write its output to any of the supported backing stores.
Streams are then used in conjunction with reader and writer classes that make it easier to read and write data to a stream by freeing you from having to work only with Byte arrays. Fundamentally, the framework includes two basic kinds of readers and writers: the base classes System.IO.TextReader and System.IO.TextWriter, whose descendants are used to read and write data as strings, and System.IO.BinaryReader and System.IO.BinaryWriter, which are used to read and write primitive types as binary data. In addition, the System.Xml namespace contains analogous XmlReader and XmlWriter classes whose descendants, such as XmlTextReader and XmlTextWriter, can read and write XML data to and from a stream. The result is that it is fairly simple to read and write different kinds of data to a particular backing store. For example, the method shown in Listing 1 uses the MemoryStream and XmlTextWriter classes to write an XML document to memory and return it from the method.
Listing 1: Using a MemoryStream and an XmlTextWriter to Write XML Data to Memory
public XmlTextReader WriteXmlChanges(DataTable dt, String pk)
{
MemoryStream s = new MemoryStream();
XmlTextWriter xmlChanges = new XmlTextWriter(s,
System.Text.Encoding.Default);
try
{
xmlChanges.Formatting = Formatting.Indented;
xmlChanges.Indentation = 4;
xmlChanges.WriteStartDocument();
xmlChanges.WriteComment("Changes for the " + [ccc]
dt.TableName + " table");
xmlChanges.WriteStartElement("diff",dt.TableName + "Diff",
"http://mycompany.org");
xmlChanges.WriteAttributeString("primaryKey",pk);
// Extract Added Rows
DataTable add = dt.GetChanges(DataRowState.Added);
if (add != null)
{
xmlChanges.WriteStartElement("Add");
foreach (DataRow row in add.Rows)
{
xmlChanges.WriteStartElement("row");
foreach (DataColumn col in add.Columns)
{
xmlChanges.WriteElementString(col.ColumnName,
row[col.ColumnName,[ccc]
DataRowVersion.Current].ToString());
}
xmlChanges.WriteEndElement(); //finish the Row tag
}
xmlChanges.WriteEndElement(); //finish the Add tag
}
xmlChanges.WriteEndDocument(); //finish the document
xmlChanges.Flush();
xmlChanges.Close();
s.Position = 0;
return new XmlTextReader(s);
}
catch (IOException e)
{
logError(e, dt);
return null;
}
catch (XmlException e)
{
logError(e, dt);
return null;
}
catch (Exception e)
{
logError(e, dt);
return null;
}
}
You'll notice that the constructor of the XmlTextWriter method accepts a stream to which the data will be written—in this case, it is passed an instance of MemoryStream. Because the constructor simply accepts a Stream, any of the derived Stream classes could have been used, for example, to write the XML document directly to a network socket. After the WriteEndDocument method of the XmlTextWriter finishes the XML document, the Flush method is called to ensure that all data is flushed to memory. This is followed by the Close method to close the Stream. The Position property then repositions the pointer to the beginning of the stream so that when it is returned, a client can begin accessing the data.