If that sounds confusing, let me give you an example. Let's say you expose a method to read a database of products, and instead of returning a List<Product> you return an IEnumerable<Product>
in iterator form (yield return). This accomplishes several good things:
The IDataReader is not passed out of
the Data Access Layer which prevents abstraction leak and resource leak potentials. You don't need to construct a full List<Product>
in memory (which could be very big) if you just want to forward iterate once. If you only want to consume up to a certain point
in the list, you won't incur
the database cost of looking up
the other items. This could give us an example like: 1: // a sample data access object class to do standard CRUD operations.
2: public class ProductDao
3: {
4: private DbProviderFactory _factory = SqlClientFactory.Instance
5:
6: // a method that would retrieve all available products
7: public IEnumerable<Product> GetAvailableProducts()
8: {
9: // must create
the connection
10: using (var con = _factory.CreateConnection())
11: {
12: con.ConnectionString = _productsConnectionString;
13: con.Open();
14:
15: // create
the command
16: using (var cmd = _factory.CreateCommand())
17: {
18: cmd.Connection = con;
19: cmd.CommandText = _getAllProductsStoredProc;
20: cmd.CommandType = CommandType.StoredProcedure;
21:
22: // get a reader and pass back all results
23: using (var reader = cmd.ExecuteReader())
24: {
25: while(reader.Read())
26: {
27: yield return new Product
28: {
29: Name = reader["product_name"].ToString(),
30: ...
31: };
32: }
33: }
34: }
35: }
36: }
37: }
The database details themselves are irrelevant. I will say, though, that I'm a big fan of using
the System.Data.Common classes instead of your provider specific counterparts directly (SqlCommand, OracleCommand, etc). This lets you mock your data sources easily
in unit testing and also allows you to swap out your provider
in one line of code.
In fact, one of
the shared components I'm most proud of implementing was our group's DatabaseUtility library that simplifies all
the database access above into one line of code
in a thread-safe and provider-neutral way.
I went with my own flavor instead of
the EL due to
the fact I didn't want to force internal company consumers to use
the EL if they didn't want to, and it made it easy to allow them to mock their database for unit testing by providing a MockCommand, MockConnection, etc that followed
the System.Data.Common model. One of these days I'll blog on that if anyone's interested.
Regardless, you often have situations like
the above where you are consuming and iterating through a resource that must be closed once you are finished iterating. For
the reasons stated above, I didn't want to return IDataReader (that would force them to remember to Dispose it), and I didn't want to return List<Product> (that would force them to hold all products
in memory) -- but
the first time I wrote this, I was worried. What if you never consume
the last item and exit
the loop? Are
the reader, command, and connection all disposed correctly?
Of course, I was 99.999999% sure
the creators of C# had already thought of this and taken care of it, but inspection
in Reflector was difficult due to
the nature of
the state machines yield return generates, so I decided to try a quick example program to verify whether or not Dispose() will be called when an iterator is broken from outside
the iterator itself -- i.e. before
the iterator reports there are no more items.
So I wrote a quick Sequencer class with a Dispose() method and an iterator for it. Yes, it is COMPLETELY contrived:
1: // A disposable sequence of int -- yes this is completely contrived...
2: internal class Sequencer : IDisposable
3: {
4: private int _i = 0;
5: private readonly object _mutex = new object();
6:
7: // Constructs an int sequence.
8: public Sequencer(int start)
9: {
10: _i = start;
11: }
12:
13: // Gets
the next integer
14: public int GetNext()
15: {
16: lock (_mutex)
17: {
18: return _i++;
19: }
20: }
21:
22: // Dispose
the sequence of integers.
23: public void Dispose()
24: {
25: // force output immediately (flush
the buffer)
26: Console.WriteLine("Disposed with last sequence number of {0}!", _i);
27: Console.Out.Flush();
28: }
29: }
And then I created a generator (infinite-loop iterator) that did
the using block for auto-Disposal:
1: // simply defines an extension method off of an int to start a sequence
2: public static class SequencerExtensions
3: {
4: // generates an infinite sequence starting at
the specified number
5: public static IEnumerable<int> GetSequence(this int starter)
6: {
7: // note
the using here, will call Dispose() when block terminated.
8: using (var seq = new Sequencer(starter))
9: {
10: // infinite loop on this generator, means must be bounded by caller!
11: while(true)
12: {
13: yield return seq.GetNext();
14: }
15: }
16: }
17: }
This is really
the same conundrum as
the database problem originally posed. Here we are using iteration (yield return) over a large collection (infinite sequence of integers). If we cut
the sequence short by breaking iteration, will that using block exit and hence, Dispose be called?
Well, let's see:
1: //
The test program class
2: public class IteratorTest
3: {
4: //
The main test method.
5: public static void Main()
6: {
7: Console.WriteLine("Going to consume 10 of infinite items");
8: Console.Out.Flush();
9:
10: foreach(var i
in 0.GetSequence())
11: {
12: // could use TakeWhile, but wanted to output right at break...
13: if(i >= 10)
14: {
15: Console.WriteLine("Breaking now!");
16: Console.Out.Flush();
17: break;
18: }
19:
20: Console.WriteLine(i);
21: Console.Out.Flush();
22: }
23:
24: Console.WriteLine("Done with loop.");
25: Console.Out.Flush();
26: }
27: }
So, what do we see? Do we see
the "Disposed" message from our dispose, or did
the Dispose get skipped because from an "eyeball" perspective we should be locked
in that infinite generator loop?
Here's
the results:
1: Going to consume 10 of infinite items
2: 0
3: 1
4: 2
5: 3
6: 4
7: 5
8: 6
9: 7
10: 8
11: 9
12: Breaking now!
13: Disposed with last sequence number of 11!
14: Done with loop.
Yes indeed, when we break
the loop,
the state
machine that C# generates for yield iterate exits
the iteration through
the using blocks and auto-disposes
the IDisposable correctly. I must admit, though,
the first time I wrote one, I began to wonder and that led to this test. If you've never seen iterators before (I wrote a previous entry here)
the infinite loop may throw you, but you have to keep
in mind it is not a linear piece of code, that every time you hit a "yield return" it cedes control back to
the state
machine generated for
the iterator. And this state
machine, I'm happy to say, is smart enough to clean up
the using blocks correctly. I suspected those wily guys and gals at Microsoft engineered it well, and I wasn't disappointed. But, I've been bitten by assumptions before, so it's good to test and see.
Yes, maybe you knew it would or figured it would, but isn't it nice to know? And as those campy 80s G.I. Joe cartoon public service reminders always taught us, "Knowing is half
the battle...".
Technorati Tags: C#,.NET
