How to really understand Streams?


I've been working with C # and .NET for a while, and I've seen the use of streams for file reading, HTML response writing, file upload, and more. It turns out that until today I did not understand what a stream really is, when they should be used and how it works.

For example, to read a file we use the following:

using (StreamReader streamReader = new StreamReader(caminhoArquivo))
    string conteudo = streamReader.ReadToEnd();

Another example is uploading data to a Microsoft Azure blob

using (Stream stream = File.OpenRead(caminhoArquivo))

And another example, which does not involve files, is to write the content of an HTTP response in an OWIN middleware. Searching a little about streams I found the following:


We have an abstract class that represents a sequence of bytes in which we can perform read and write operations. This abstract class is called Stream.

That way a stream is a sequence of bytes? Even so, when should this be used? Why do I use streams in these cases? In the case of the HTTP response it is even more difficult to understand, could not we just write the response text in a stream?

asked by anonymous 07.02.2015 / 01:24

1 answer


Almost this. Stream is a sequence of data, elements. It may be bytes , it is the most common, but not necessarily. Individual elements may be more complex or simpler objects, such as bit . If we were to translate the word we would probably call it continuous flow. It's just a concept.

Flow is the key word there. stream is created precisely to avoid having to deal with the whole. With it you can go manipulating the desired data on demand.

With them the application works with a connection model always. The code initiates the connection by opening the stream and can use it until it is closed by the code, eventually decided through signaling received during the process. The connection need not be an external mechanism, just having a collection of data.


This data may be available as a whole or not. It can come / go slowly solving a potential problem of memory overhead (of any kind), congestion and temporary absence of transmission. While the stream is open and gives no indication that it has finished it can provide new data even if a wait is required.

Another advantage is that you do not need to know how the information comes / goes, no matter the source or target. You do not need to know that the stream works in a certain way. If the source / target of data is a file on disk, in memory, or object in memory, a transmission of the network in any protocol, a database connection, communication with another process, an algorithm that manages this data on demand (random numbers, for example) or other form, ie source / target data problem with stream .

The program that will consume the stream does not need to know how the data reaches it. This is why it is called an abstract class (nothing to do with% of OOP%, even though this mechanism is used in OO languages to implement it). You do not need to know the concrete implementation of the source / target data. You also do not need to know the mode used for data provision. Several mechanisms can be used within it without the stream consumer code needing to be aware.

Perhaps one cited example that fits the explanation is the generation of random. Generating random numbers does not mean that the generator is a stream . Just as generating a string is not. The stream encapsulates data. So a random generator can be the data source of the stream, but not the stream. We can not call any sequence of stream elements, it needs to meet the protocol established by it.

A stream can even manipulate data in certain situations if there is any reason for its mechanism to provide something like this. Yet the programmer does not need to know internally how and why he does it, he just needs to understand how the data comes and goes through them.

APIs that accept stream

In theory, if an API wants to provide a way to work with data without the stream , that's fine. An HTTP response could work directly with the text, but would lose all these advantages mentioned above. For example, abstract does not work with stream .

Obviously, if the API only accepts communication through streams you will have to do it this way. Overall it only has advantages in using it this way.


Maybe someone can put it that there is a disadvantage to having an extra layer, which slightly increases the complexity and consumption of processing. But they are very small things that are not usually relevant near the advantages presented by their use. I will stress that the extra cost of its use is minimal in every way.

An actual implementation example

Maybe looking at the class code System.IO.File.WriteAllText can help (or hinder :)) understand its functioning. Note that it is only the basis for classes that actually provide concrete streams that know how to handle particular sources / targets. It may be interesting to analyze the code of some classes that inherit from it, such as Stream .

07.02.2015 / 02:02