A Basic View of Data: Files | COBOL and Visual Basic on .NET: A Guide for the Reformed Mainframe Programmer

Let's start by reflecting on the most basic types of data files that are available on the mainframe:

Queued Sequential Access Method (QSAM)
Partitioned Access Method (PAM, but more commonly known as partitioned dataset or PDS)

Virtual Storage Access Method (VSAM)

Note	On the mainframe, database-stored data is as common as QSAM, PDS, and VSAM data formats. I further discuss database- oriented data formats the section "An Extended View of Data: Data Repositories" later in this chapter.

Any discussion of mainframe data would not be complete without mention of the QSAM file (rather, the flat file ). For a lot of us reformed mainframe types, this simply structured, easily accessed file served as our initial entry into program-matic data processing. (Well, that is, for those of us who have no idea what keypunch cards are.) Combine the QSAM file with JCL, and we were happily creating great applications that consisted of nothing more that a few IEBGENER utility programs being executed in succession, copying one QSAM file on top of another, and perhaps sorting and printing the data.

In those early days, just as you had gotten used to Logical Record Lengths (LRECLs) and Data Control Blocks (DCBs), it happened . Someone came along and pointed out that the PDS file that you had been using to store your JCL Jobs could also be used to store regular text. Then, you used these PDS members for all of your basic data storage needs (e.g., status reports , resumes, and so on). Perfecting your abilities to read and write programmatically, your QSAM and PDS files meant that now you were really a data processing professional.

Let's jump forward a few mainframe years , when you " graduated " to VSAM files. For many of you, this would have occurred around the same time that you were making your entry into mainframe CICS programming. With VSAM files, you were now ( generally ) able to choose between sequential or random access of your data. You were introduced to the IDCAMS utility (which was comparable to the IEBGENER utility). So, with QSAM, PDS, and VSAM files, you went along creating mission-critical solutions.

Users Putting the "I" in "I/O"

It's likely that you've written some type of application that accepted user input. It may have been an online mainframe CICS application that had the user entering values on the screen. Besides the fact that you had to add input validation logic, you were now getting input directly from the user. Similar to getting input from files, you had the opportunity to process this direct user input data as you saw fit. In Chapter 13, when I further discuss user interaction, you'll be introduced to the .NET ways of accepting user input (including input validation and other techniques).

As you make your transition to the Windows platform, you will be looking for suitable replacements for the common mainframe data file formats of QSAM, PDS, and VSAM. Naturally, you will want to explore data access in the absence of mainframe JCL. Equally (if not more) important, you are eager to find out what type of support .NET provides for Windows-based basic data access.

Moving from Flat Files to Text Files

Simply put, the Win32-based text file (or American Standard Code for Information Interchange [ASCII] file) is going to be your replacement for the mainframe type of flat file (or Extended Binary Coded Decimal Interchange Code [EBCDIC] file).

Note	The Windows NT file system (NTFS) is the preferred underlying system-level application responsible for general file allocation concerns in the Windows 2000 environment. The older Win32 file systems, file allocation table (FAT) and FAT32, continue to be supported for backward compatibility.

On the Windows environment, text-type files are generally recognized as the files that are readable by humans . Suffix extensions are associated with each grouping of text-type files (.txt, .xml, and .htm, just to name a few). The groupings of text-type files that use .txt as the suffix extension are sometimes simply referred to as text files (even though this grouping is just one among other text-type files). For the remainder of this chapter, I use this particular grouping of text-type files (files ending with .txt), and I also loosely refer to them as "text files."

File-type suffix extensions typically have a default program associated with them for reading/editing. Therefore, each specific grouping of text-type files can be associated with a specific reading/editing program. The default program typically associated with text files (files with the .txt suffix, in this context) is the Windows utility Notepad.

Tip	You can override the default program-to-file-type association in Windows. This is generally referred to as the Open With option on the Windows platform. Consult your Windows Help text for further details. (Search on the topic "File Type" or "File Name Extension.")

Outside of your own application development, you can use Notepad to easily create and edit text files (I discussed Notepad in Chapter 3 in the section "Microsoft Office and Notepad"). Understanding this, you are then faced with the choice of how to access text files (when capturing and modifying your own data): the traditional legacy way or the newer .NET way.

Tip

On the Windows platform, when you want to create a text file, you simply create it. Gone is the need to worry about LRECLs, block sizes, and DCBs. Variable-length and fixed-length record formats . . . huh? What does that mean? The questions you might ask during the creation of a Win32 text file might involve file name and folder choice for saving. That is about it. Pretty simple. Oh ”and no JCL.

Accessing Text Files in .NET the Old Way

Before you throw up your hands, bear with me for a moment. You might ask, "Why on earth even mention doing something the ˜old way' on the .NET platform?" Well, I suppose it comes down to dollars and cents ” or maybe dollars and sense : the dollars that it may cost to rewrite the application using the newer approach (in most cases, the better approach) and the sense that it typically makes to do so. My suggestion is that if you have time, quickly learn and master the "newer" way and use it. If you don't have time, simply use the "older" way and effortlessly port your existing legacy business logic to your new .NET application. Now, let's take a look at both the traditional approach (on .NET) and the modern approach (on .NET).

Note

Large vendors (e.g., Microsoft and Fujitsu) include support for the traditional syntax mainly to ease the upgrade experience (both software-wise and training-wise). As they do, you should remain sensitive to the financial bottom line that exists in every organization. In some cases, your legacy application may have some life left in it. That is, according to the expected life span of your legacy application, management may have issues with expediting the trashing of a software investment.

COBOL .NET Code Snippet

The pseudo-code snippet in Listing 10-1 (showing a basic data access structure) should look familiar to you. Even though this code is being presented in the context of COBOL .NET sample code, notice that the approach is basically the same as that you would expect to see in the traditional mainframe COBOL code. Although the SELECT/ASSIGN statement may look a little strange , the remaining statements (OPEN, WRITE, CLOSE, and so forth) are the same COBOL statements that you have used in your legacy mainframe applications. It is great to know that you can continue to use this type of legacy COBOL syntax in your new COBOL .NET development.

Listing 10-1: A Pseudo-Code COBOL .NET Snippet Showing Traditional File Access Syntax

 IDENTIFICATION DIVISION. PROGRAM-ID. My-program. . . .  FILE-CONTROL.       SELECT a-file         ASSIGN TO "C:\SampleText.txt". DATA DIVISION  FILE SECTION.  FD a-file  01 your-record PIC X(80). PROCEDURE DIVISION.     OPEN OUTPUT a-file.   [Open mode could have been I-O, INPUT, or EXTEND]     WRITE your-record.   [You may have READ your a-file]     CLOSE a-file.  . . . END PROGRAM My-program.

This continued traditional syntax support is, of course, a good thing when you are porting existing coded logic from the mainframe platform over to the Windows platform. There is one significant caveat to this convenience: If you are developing new code, you might consider leveraging the newer .NET way of accessing files. I believe this latter approach (using the .NET Framework) will further support your ultimate retraining goal.

VB .NET Code Snippet

Yes, Visual Basic .NET (VB .NET) also supports a traditional approach. Knowing this may be of more value to those with a legacy Visual Basic (that is, Visual Basic 6.0) background, but it may (one day) be of use to you as well. Who knows ? You may end up being tasked with converting legacy Visual Basic 6.0 applications over to VB .NET. After all, you are acquiring .NET expertise. You will be surprised at the doors that you are opening for yourself.

The following VB .NET pseudo-code snippet demonstrates a typical way, ^[1] using traditional Visual Basic 6.0 syntax, to access text file data in a .NET application.

Listing 10-2: VB .NET Pseudo-Code Snippet Showing a Traditional Approach of Accessing a Text File

 . . . Dim myString As System.String Dim myInt As System.Int32 . . . 'The code below Demonstrates how to Write to the Text file. 'Open File Number 1 Microsoft.VisualBasic.FileOpen(1, "MyFile.txt", OpenMode.Output) 'Write a String to File Number 1 Microsoft.VisualBasic.Write(1, "This is a Test") 'Write a Number to File Number 1 Microsoft.VisualBasic.Write(1, 99) 'Close File Number 1 Microsoft.VisualBasic.FileClose(1) 'The code below Demonstrates how to read from the Text file. 'Open File Number 1 Microsoft.VisualBasic.FileOpen(1, "MyFile.txt", OpenMode.Input) 'Read a String from File Number 1 Microsoft.VisualBasic.Input(1, myString) 'Read an Integer from File Number 1 Microsoft.VisualBasic.Input(1, myInt) 'Close File Number 1 Microsoft.VisualBasic.FileClose(1) . . .

Whether you bilingual developers are coding in COBOL .NET or VB .NET, you are certainly ready now to see the newer .NET way of accessing Win32-based text file data.

Accessing Text Files in .NET the New Way

Microsoft has created a .NET Framework namespace specifically designed for data access. This namespace, System.IO , contains a healthy number of delegates (sorry, no interfaces), classes, enumerations, and structures. Although it is advisable to eventually familiarize yourself with each one of them, I will introduce only the following few here: ^[2]

File (or System.IO.File )
TextReader (or System.IO.TextReader )

TextWriter (or System.IO.TextWriter )

Tip	There are System.IO objects available that support path /directory logic as well as security/access logic. There are even special methods you can use when reading and writing binary data. As time (and your need) dictates, do explore the System.IO namespace.

Reviewing System.IO.File

Let's start by using the Class Viewer (WinCV.exe) tool to take a quick peek into the System.IO.File class. ^[3] It has a handful of members, as Listing 10-3 shows.

Listing 10-3: The Methods of the System.IO.File Class

 // from module 'c:\winnt\microsoft.net\framework\v1.0.3705\mscorlib.dll' public sealed class System.IO.File :  object . . .     // Methods public static System.IO.StreamWriter AppendText(string path); public static void Copy(string sourceFileName, string destFileName); public static void Copy(string sourceFileName, string destFileName, bool        overwrite); public static System.IO.FileStream Create(string path); public static System.IO.FileStream Create(string path, int bufferSize); public static System.IO.StreamWriter CreateText(string path); public static void Delete(string path); public virtual bool Equals(object obj); public static bool Exists(string path); public static System.IO.FileAttributes GetAttributes(string path); public static DateTime GetCreationTime(string path); public virtual int GetHashCode(); public static DateTime GetLastAccessTime(string path); public static DateTime GetLastWriteTime(string path); public Type GetType(); public static void Move(string sourceFileName, string destFileName); public static System.IO.FileStream Open(string path, System.IO.FileMode mode); public static System.IO.FileStream Open(string path, System.IO.FileMode mode,               System.IO.FileAccess access); public static System.IO.FileStream Open(string path, System.IO.FileMode mode,               System.IO.FileAccess access, System.IO.FileShare share); public static System.IO.FileStream OpenRead(string path); public static System.IO.StreamReader OpenText(string path); public static System.IO.FileStream OpenWrite(string path); public static void SetAttributes(string path, System.IO.FileAttributes                fileAttributes); public static void SetCreationTime(string path, DateTime creationTime); public static void SetLastAccessTime(string path, DateTime lastAccessTime); public static void SetLastWriteTime(string path, DateTime lastWriteTime); public virtual string ToString(); } // end of System.IO.File

Notice that each member of the System.IO.File class is a Public Static method (the Class Viewer tool uses Visual C# .NET or just C# syntax in its display). This, of course, is in reference to the access attributes being shown. Recall that if I were coding in VB .NET, I would have rephrased this as Public Shared method.

From the list of methods in Listing 10-3, take a closer look at the Open method. You can see that there are actually three methods shown for Open. This is an example of the object-oriented overloading approach. In other words, the Openmethod is overloaded. Looking at the overloaded Open methods (displayed using C# syntax)

 . . . public static System.IO.FileStream Open(string path, System.IO.FileMode mode); public static System.IO.FileStream Open(string path, System.IO.FileMode mode,               System.IO.FileAccess access); public static System.IO.FileStream Open(string path, System.IO.FileMode mode,               System.IO.FileAccess access, System.IO.FileShare share); . . .

you can see that if you were to code System.IO.File.Open , the type of object that would be returned is a System.IO.FileStream object. As its name indicates, FileStream is a class housed in the System.IO namespace. By using the overloaded approach, the only thing that differs with each overloaded Open method is the input parameters. Depending on your use of input parameters, you will dictate which Open method you actually use. With the exception of the string/path input parameter, the System.IO.FileMode , System.IO.FileAccess , and System.IO.FileShare input parameters are enumerations from the System.IO namespace.

Reviewing System.IO.TextReader

This next class, System.IO.TextReader , contains just over a dozen methods. Please take a moment to review Listing 10-4, which contains the Class Viewer display that shows these few methods.

Listing 10-4: The Methods of the System.IO.TextReader Class

 . . .  public abstract class System.IO.TextReader :  . . .  // Methods  public virtual void Close();  public virtual System.Runtime.Remoting.ObjRef CreateObjRef(Type                 requestedType);  public virtual bool Equals(object obj);  public virtual int GetHashCode();  public virtual object GetLifetimeService();  public Type GetType();  public virtual object InitializeLifetimeService();  public virtual int Peek();  public virtual int Read();  public virtual int Read(char[] buffer, int index, int count);  public virtual int ReadBlock(char[] buffer, int index, int count);  public virtual string ReadLine();  public virtual string ReadToEnd();  public static System.IO.TextReader Synchronized(System.IO.TextReader reader);  public virtual string ToString();  . . .

You will notice that the System.IO.TextReader class is defined as Public Abstract (near the top of the Class Viewer display). This is C# syntax for Public MustInherit. In other words, you can't use the System.IO.TextReader class directly ”you must first inherit this class. Then, you simply take advantage of System.IO.TextReader via your derived class. For your convenience, the majority of the methods (as shown in Listing 10-4) are defined as Public Virtual (again, C# syntax). You can interpret this as Public Overridable. So, if you found the need to, you could actually override most of the System.IO.TextReader methods in your derived class.

You are in luck. Microsoft has actually provided two .NET " derived classes" ”two classes that both inherit from System.IO.TextReader. These classes are System.IO.StreamReader and System.IO.StringReader . Of course, if you were so looking forward to exercising your object orientation skills, feel free to create your own derived classes (that inherit from System.IO.TextReader). Just remember, you also need to add all of the additional logic to override the appropriate methods. In other words, plan to use these two derived classes (System.IO.StreamReader and System.IO.StringReader) that Microsoft has provided as part of the .NET Framework each time that you want the functionality exposed by the System.IO.TextReader class .

Note

My emphasis here on the word "derived" is actually misleading. As you learned in Chapter 9 (in the section "Where Do .NET Objects Come From?"), all .NET Framework classes are either directly or indirectly derived from the System.Object class. So, these are two classes that just happen to derive from the System.IO.TextReader class.

Take a moment to review each of the System.IO.TextReader methods carefully . For example, take note of the following facts:

The Read method is overloaded.
There are several methods for reading (e.g., ReadLine , ReadBlock , and ReadToEnd ).
The Peek method returns an Integer.
The ToString method returns a String.

The name of the System.IO.TextReader class is obviously self-documenting . Given that fact, it should not surprise you that there is a .NET Framework class for writing text that has the name System.IO.TextReader.

Reviewing System.IO.TextWriter

This particular data access “oriented class also happens to be an abstract class (that must be inherited and used via a derived class). Listing 10-5 shows a partial Class Viewer display of the System.IO.TextWriter class.

Listing 10-5: The System.IO.TextWriter Class

 . . . // Methods public virtual void Close(); . . . public virtual void Write(char[] buffer); public virtual void Write(char[] buffer, int index, int count); public virtual void Write(string format, object[] arg); public virtual void Write(string format, object arg0); public virtual void Write(string format, object arg0, object arg1); public virtual void Write(string format, object arg0, object arg1, object arg2); public virtual void Write(int value); public virtual void Write(UInt32 value); public virtual void Write(char value); public virtual void Write(bool value); public virtual void Write(long value); public virtual void Write(Decimal value); public virtual void Write(string value); public virtual void Write(object value); public virtual void Write(UInt64 value); public virtual void Write(float value); public virtual void Write(double value); public virtual void WriteLine(); public virtual void WriteLine(char[] buffer); public virtual void WriteLine(char[] buffer, int index, int count); public virtual void WriteLine(string format, object[] arg); public virtual void WriteLine(string format, object arg0); public virtual void WriteLine(string format, object arg0, object arg1); . . . public virtual void WriteLine(Decimal value); public virtual void WriteLine(string value); public virtual void WriteLine(object value); public virtual void WriteLine(double value); public virtual void WriteLine(int value); public virtual void WriteLine(bool value); public virtual void WriteLine(char value); public virtual void WriteLine(UInt32 value); public virtual void WriteLine(float value); public virtual void WriteLine(UInt64 value); public virtual void WriteLine(long value); . . .

Wow! Now, that is what I call truly exercising an object-oriented design. Take a look at the extent to which the two methods Write and WriteLine are overloaded. You can see that the System.IO.TextWriter class supports practically all data types. Using the appropriate derived class, you can write data to your heart's content. Among your choices of derived classes provided by Microsoft (as part of the .NET Framework) are

System.IO.StreamWriter
System.IO.StringWriter
System.Web.HttpWriter
System.Web.UI.HtmlTextWriter

Demonstrating How to Access Data in Text Files

Now that you have reviewed the System.IO.File, System.IO.TextReader, and System.IO.TextWriter classes, it is time for a quick demonstration. The code shown in the following two sample projects, SystemIOExampleVB and SystemIOExampleCobol, should help you get off to a great start. Please review the VB .NET and COBOL .NET code. When you execute the project, a few lines will display on your console that show the data contents of your text file.

Note	When you execute the sample applications, a text file will be created. Until you explicitly delete the newly created text file (named myTextFile.txt), the file will continue to exist.

Listing 10-6 shows the data access logic in a VB .NET sample project.

Listing 10-6: VB .NET Project SystemIOExampleVB Demonstrating the Use of the System.IO Namespace

 Module Module1       Sub Main()              Call WriteMyData()              Call ReadMyData()       End Sub            Sub WriteMyData()                  'Declare a StreamWriter Object              'which inherits System.IO.TextWriter              Dim myStreamWriter As System.IO.StreamWriter              'Return Value of File.CreateText Method = StreamWriter              myStreamWriter = _              System.IO.File.CreateText("myTextFile.txt")              Dim myInt As System.Int32              For myInt = 0 To 3                   myStreamWriter.WriteLine("This is a Test")              Next              'Close the StreamWriter and file              myStreamWriter.Close()        End Sub            Sub ReadMyData()              'Declare a StreamReader Object              'which inherits System.IO.TextReader              Dim myStreamReader As System.IO.StreamReader              'Return Value of File.OpenText Method = StreamReader              myStreamReader = System.IO.File.OpenText("myTextFile.txt")              'Read Until Reaching the End of the StreamReader              Dim myReadString As System.String              Do Until myStreamReader.Peek = -1                    myReadString = myStreamReader.ReadLine()                    Console.WriteLine(myReadString)              Loop              'Close the StreamReader and file              myStreamReader.Close()                 Console.WriteLine("Press Enter to Exit.")              Console.ReadLine()       End Sub End Module

Listing 10-7 shows similar data access logic implemented in a COBOL .NET

sample project.

Listing 10-7: COBOL .NET Project SystemIOExampleCobol Demonstrating the Use of the System.IO Namespace

 000010 IDENTIFICATION DIVISION. 000020 PROGRAM-ID. MAIN. 000030 ENVIRONMENT DIVISION. 000040 CONFIGURATION SECTION. 000050 REPOSITORY. 000060* .NET Framework Classes 000070*    Declare a StreamWriter & StreamReader Object 000080*    which will inherit from  000090*    System.IO.TextWriter & System.IO.TextReader  000100    CLASS Sys-StreamWriter AS "System.IO.StreamWriter" 000110    CLASS Sys-StreamReader AS "System.IO.StreamReader" 000120    CLASS Sys-Integer AS "System.Int32" 000130    CLASS Sys-String AS "System.String". 000140* 000150 DATA DIVISION. 000160 WORKING-STORAGE SECTION. 000170   77 mySys-StreamWriter OBJECT REFERENCE Sys-StreamWriter. 000180   77 mySys-StreamReader OBJECT REFERENCE Sys-StreamReader. 000190   77 mySys-String OBJECT REFERENCE Sys-String. 000200   77 mySys-Integer OBJECT REFERENCE Sys-Integer. 000210   77 myDisplayString PIC x(30). 000220   77 myInt PIC S9(9) COMP-5. 000230   77 myOtherInt PIC S9(9) COMP-5. 000240   01 NULL-X PIC X(1). 000250 PROCEDURE DIVISION. 000260  000270    Perform 1000-WriteMyData. 000280    Perform 2000-ReadMyData. 000290    Stop Run. 000300 1000-WriteMyData. 000310  000320*    Explicitly Create StreamWriter Object with Constructor 000330    INVOKE Sys-StreamWriter "NEW" 000340    USING BY VALUE "myTextFile.txt" 000350    RETURNING mySys-StreamWriter 000360  000370    PERFORM VARYING myInt 000380    FROM 0 BY 1 UNTIL myInt >= 4 000390       INVOKE mySys-StreamWriter "WriteLine" 000400          USING BY VALUE "This is a Test" 000410    END-PERFORM. 000420*    Close the StreamWriter and file 000430    INVOKE mySys-StreamWriter "Close". 000440 2000-ReadMyData. 000450  000460*    Explicitly Create StreamReader Object with Constructor 000470    INVOKE Sys-StreamReader "NEW" 000480    USING BY VALUE "myTextFile.txt" 000490    RETURNING mySys-StreamReader 000500  000510    PERFORM UNTIL myOtherInt = -1 000520       SET mySys-String TO mySys-StreamReader::"ReadLine" () 000530       SET myDisplayString TO mySys-String  000540       DISPLAY myDisplayString 000550*    Read Until Reaching the End of the StreamReader 000560       SET mySys-Integer TO mySys-StreamReader::"Peek" () 000570       SET myOtherInt to mySys-Integer 000580    END-PERFORM 000590*   Close the StreamWriter and file 000600    INVOKE mySys-StreamReader "Close". 000610 000620    DISPLAY "Enter X and Press Enter to Exit.". 000630    ACCEPT NULL-X. 000640 END PROGRAM MAIN.

You will notice that both sample projects (SystemIOExampleCobol and SystemIOExampleVB) make use of the System.IO namespace. Although the syntax varies slightly between the two languages, the approach is similar for accessing data in text files. The next step could be to explore further the System.IO namespace. With practice, you will be better prepared to take advantage of these (and other) .NET Framework classes to support your basic needs to write data to and read data from text files.

I have discussed both traditional and state-of-the-art approaches to accessing data in text files. Now you will switch gears and move beyond the text file and flat file. As you well know, there are times when a flat file or text file will not meet all of your development needs.

What About the PDS and VSAM Data Formats?

Coming from a legacy mainframe COBOL environment, you will likely seek out something representative of the mainframe PDS and VSAM types of data formats. These "other" data formats certainly have had their time and place. So, on that note, their time was yesterday , and their place was on the mainframe.

All right, to be fair, there are comparable replacements. The Win32 directory/folder structure mimics the functionality of the PDS data format. You can read from, navigate the "tree" structure of, and write to the Win32 directory/folder data structure. As for VSAM, a product available from Fujitsu called the COBOL File Utility that ships with NetCOBOL for .NET allows you to create indexed text files. These indexed text files mimic the functionality of the mainframe VSAM files that you have used through the years.

Besides the file utility products (such as the one Fujitsu provides), many companies are following a growing trend where they will create or purchase an application programming interface (API) to access mainframe VSAM files. The modern acronym being used for these types of APIs is EAI, which stands for Enterprise Application Integration .

Tip	A reformed mainframe programmer can be a big asset to his or her organization when EAI and host integration projects are launched.

An Opportunity to Redefine Data

When I decided to transition over to the Windows/Web development world, ^[4] among other things, I remember having to actually redefine data. You, reading this, may assume that I am using the phrase "redefining data" to refer to the REDEFINES data definition clause used in COBOL programs. Actually, I am referring to the notion that an expanded definition of the term "data" does exist. In other words, there are many things (other than QSAM, PDS, and VSAM text-type structures) that can be categorized as data, especially when you are doing Windows/Web development.

Take image files, for example. As a Windows/Web developer, you may grow to recognize an image file as just another type of data file. You could become familiar with image formats such as bitmaps, Joint Photographic Experts Group (JPEG) files, and Tagged Image File Format (TIFF) files. In your Web development work, you will certainly work with the Graphics Interchange Format (GIF) image file format. If you are lucky, you may even end up working with GIF animation files. ^[5] They are part of an impressive list that consists of data files (while redefining the term "data") available for your application to consume . (I further discuss graphic data in the next section, "The .NET Framework Supports Graphic Data.")

Note

.NET objects themselves can even be considered to be data. .NET has a feature referred to as object serialization. With this feature, you can " turn " a previously instantiated object into XML structured data. The serialized object can then be persisted (saved) or transmitted. Later, the deserialization process brings the object back to life. Chapter 12 goes into this topic in more depth.

Once you redefine what data actually is (or rather, what is data), the list is endless. In addition to image files, there are data files for supporting audio and video needs. Speech, network streams, and even HTML would also fall into the (redefined) data category. The types of data formats that I have listed in this section ("A Basic View of Data: Files") are those that are more "file" oriented. In other words, as exhaustive as this "redefined" data list appears, it just scratches the surface. For example, a look beyond the data "files" will reveal the following "other" types of data:

Data repositories (see the section "An Extended View of Data: Data Repositories" later in this chapter)
Metadata (see the section "A Meta View of Data: Metadata" later in this chapter)

The redefinition of data may sound like a stretch, I know. It was a stretch for me. Legacy mainframe development tools (for the most part) simply were not equipped to support these types of data. As you've probably guessed, the .NET platform is equipped to support all of your data needs.

The .NET Framework Supports Graphic Data

In the event that your application needs to work directly with graphic data, you will want to familiarize yourself with several .NET Framework namespaces:

System.Drawing for basic graphics functionality
System.Drawing.Drawing2D for advanced two-dimensional graphics
System.Drawing.Imaging for advanced imaging functionality
System.Drawing.Text for advanced typography functionality
System.Drawing.Design for design-time user interface and drawing
System.Drawing.Printing for print- related services

These .NET namespaces all have one thing in common (other than "System.Drawing" being part of their name): They each support a technology known as GDI+, which is the successor to Graphical Device Interface, or GDI. GDI+ is a broad and powerful graphics-based technology worthy of further research. For your convenience, I have provided a few GDI+ references at the end of this chapter in the "To Learn More" section.

Walk Before Running with GDI+

In the meantime, it is possible to accomplish your most basic (graphically oriented) tasks without an extensive investment into GDI+ expertise. Start with something simple (e.g., the System.Drawing.Graphic class) and build up from there. Better yet, how about the System.Drawing.Printing namespace? That could be a starting point.

You could combine your knowledge of the System.IO.StreamReader class (discussed earlier in the section "Reviewing System.IO.TextReader") with classes from the System.Drawing.Printing namespace. This will be helpful when you want to read a regular text file for the purpose of printing the contents of the file. You can even add Print Preview functionality into your application using features you will find in the System.Drawing.Printing PreviewPageInfo and PreviewPrintController classes .

Note

Depending on the type of business applications that you will be writing, your perspective toward "a basic view of data" could vary significantly. For example, rather than depending on Win32-based text files, you could find yourself working with many "other" types of data formats, including image files.

Have fun exploring these "graphic" data namespaces. As you encounter the need to incorporate graphic data into your applications, your use of them (as well as your comfort in using them) will increase. As you grow to look at image files as just another data file format, you will also grow to see these System.Drawing namespaces as just another set of namespaces. Seek to take advantage of the delegates, interfaces, classes, enumerations, and structures in the System.Drawing namespaces.

Having fun so far? Good. Perhaps this is a good time to refresh your hot or cold beverage and rest your eyes for a moment or two. You will want to be fully prepared for the rest of the discussion. You will consider yet another view of data: an extended view. The upcoming extended view will introduce the group of data formats commonly referred to as data repositories.

^[1] Some Visual Basic 6.0 developers have used an alternative traditional approach to access data in Win32 text files. This other approach is commonly referred to as the FileSystemObject (FSO) approach. For our purposes here, please just make a note that this other traditional approach does exist.

^[2] You will actually use a few additional classes and enumerations simply through the course of using the three classes File, TextReader, and TextWriter.

^[3] Yes, you can choose to abbreviate System.IO.File to just File (and then remember to use the IMPORTS statement when coding in VB .NET). However, I generally find it more useful to just go ahead and use the entire namespace. This approach (to me) seems more informative and self-documenting.

^[4] The day I joined forces with the dark side.

^[5] For those interested in programming with graphic data, be sure to do a search on the Macromedia Flash technology. A reference is included at the end of this chapter to give you a head start.