|
|
In Chapter 14, we built our first version of the SRS as a command-line driven application that focused on the domain classes called out by our model: Person, Professor, Student, Course, Section, ScheduleOfClasses, Transcript, and TranscriptEntry. The Main method of the SRS driver class was written simply to instantiate objects of the various types and to put them through their paces, as a means of testing that we've implemented the logic of their methods correctly. But, the SRS application as written isn't useful as an "industrial-strength" application yet because
It "hard codes" all of its objects/data.
It provides no means of saving the state of the objects from one invocation of the application to the next, a process known as persisting data.
Most "industrial-strength" information systems requiring significant user interaction rely on a graphical user interface (GUI) for such interaction.
In essence, we've developed the core of our application by creating the classes that represent the domain model. In this chapter, we're going to revise our SRS application to provide a means for reading/writing data to/from files so that we can remedy the first two of these shortcomings; then, in Chapter 16, we'll remedy the third deficiency by adding a graphical user interface front-end as shown in Figure 15-1.
In this chapter, you'll get to apply much of what you've learned about C# in Chapter 13, and to actually see it in action in the SRS. You'll also learn the following techniques:
How we approach file input/output in C#
An approach for parsing tab-delimited ASCII records to initialize an object's state, or to initialize a collection of objects
A means of persisting an object's state in a simple ASCII file
How to prepare a "test scaffold" Main method for testing isolated classes
How proper encapsulation streamlines client code (for example, the SRS Main method)
|
|
