Web applications, by nature, are multiuser applications, so whenever you do anything, you need to consider resource management carefully. Holding resources exclusively for a single user affects scalability; therefore, the type of file access that is common in single-user Windows applications has catastrophic effects for a Web application. The multiuser requirement affects everything. For example, many applications let users store personalization data—settings—such as font and color choices, default folder paths, and so on. In a standard Windows application, you'd read the user's settings file and then keep the data in memory for the lifetime of the application so that you could refer to it as needed. Whether you can use the same strategy in a Web application depends heavily on how scalable you need the application to be. Suppose the maximum size of a user's settings file is 50KB. If you have 10 people using the application simultaneously, no problem; the data would require only half a megabyte of memory at most. But suppose you have 100 or 1,000 people using the application. Suddenly, the memory requirement for the settings data alone jumps to 50MB or 500MB, and that's without taking any working data into account.
Next, suppose you let users save a file. With a single-user application, you can generally let the person save the file with any name he wishes. But in a Web application, you're unlikely to let users select filenames at all because the chances of collision—two people selecting the same name—are too high. Simply denying users the capability to save a file because a file with that name already exists is an unpalatable option. Instead, you might implement a strategy whereby users think they get to select a filename, but your application creates the real filename using a machine-generated filename, so collisions can't occur.
Finally, if you've worked with almost any other modern language in addition to VB, file access using C# will be easy. If you worked with the Scripting FileSystemObject that shipped with classic ASP and VB6, you'll be comfortable with C# file access almost immediately, and you can skip quickly through the first part of this chapter. But if you're used to the standard VB Open For Binary Access Shared type of syntax, the model has changed. Fortunately, it's changed for the better.
In .NET, file access has been abstracted by one level. That means you should change the way you think about file access. Rather than "tell the operating system to open a file," the way to think about file access is in two steps: First, use the File class or create a FileInfo object. These operations return a Stream instance. Streams read from and write to files, memory locations, and strings. Then, you use the returned Stream to read and/or write data to the file. The reason it's better is that all the operations are similar—you'll see that writing data or reading data to/from a memory buffer, a file, or any object that supports an IStream interface is essentially the same. While the changes force you to change the way you think about files, they also immediately give you the capability to treat all types of I/O in almost exactly the same way.
Was this article helpful?