And while streams are not necessarily needed for things like reading
from the files, or a socket (I'm surprized no one picked up on this), it is
very, very convenient to have these things represented in a ubiquitous,
unified model.
For example, if you extend a WebRequest/WebResponse class, you have to
override the GetRequestStream method. The beauty of this abstraction in
returning a Stream is that the Stream can be any derivation you want, so it
doesn't have to necessarily be network related. As long as you stick to the
model of what a Stream is, you are fine, which allows for a deep level of
customization.
This is really true about abstract classes and interfaces in general,
when they are designed properly, and you stick to the meaning of the
contract (not the implementation), you gain incredible flexibility.
--
- Nicholas Paldino [.NET/C# MVP]
-
mv*@spam.guard.caspershouse.com
"Marc Gravell" <ma**********@gmail.comwrote in message
news:O2**************@TK2MSFTNGP06.phx.gbl...
Further - for BLOB manipulation, database streams can come into play (just
to counter your "just need to use databases" point).
Another biggie would be compression; very convenient via streams; a pain
otherwise.
Serialization works via streams, and that is a common theme in many
scenarios (albeit often wrapped via XmlReader/XmlWriter).
I guess how much you use them depends on what you tend to do; if you are
just throwing some aspx pages together then you probably won't see them
much; if you are writing a comms / security layer you'll see them lots.
Marc