>>>
Today, the only thing that SqlConnection's Dispose method does is make
sure the connection is closed. Tomorrow, it could do something else.
If you want to be a good citizen, call Dispose and pretend that you
don't know what it does.
When dealing with objects that use the Close pattern, Close and Dispose
*should* be, at least, functionally similar, any that are not are
broken(I
I would expect Close to be a subset of Dispose.
Why? There is *no* convention that says so. Infact DIspose is there to
"pefrom application-defined tasks associated with freeing, releasing, or
resetting unmanaged resources"(para phrased from MSDN), that sounds more like
a subset of Close to me.
For all you know dispose does not close the object or does anything else
similar to Close. The only saving grace Dispose has is that, as common
practice, Dispose and Close are similar or identical. In any other case you
end up with broken API's and a useless IDisposable contract.
If Close is anything but an equal to Dispose you end up with scenarios where
users are forced to know what each means and to apply each particular method
in the circumstance nessecery. That ends you with two seperate states
(Closed and Disposed), increasing possible exceptions and the complete
complexity of the class itself. You end up with circumstances where objects
are only cleaned up due to one path while the other causes surprises. You
end up with scenarios where you cannot use using. In effect, if Close and
Dispose aren't considered equal, you risk Dispose having Reset or Free and
Reload sematics instead of Close semantics.
There is a reason Close exists period, and its not just to look pretty.
Using using is usually the better pattern, but that is a matter of design
and appropriatness, not requirements.
It's just wrong to believe that if an object has a Close method, that
method does the same thing as Dispose. It's also wrong to believe that
there's no need to call an object's Dispose method because you know what
Dispose does.
And by that logic it is equally wrong to assume that because an object has a
Dispose method that you can call it instead of Close. You cannot rely on
Dispose anymore than Close, guess its best to call both every time, eh? For
that matter, you can't even safely call Dispose if you don't know what it
does because that may *reset* the content without flushing buffers or do
things which makes close illogical or surprising(like recycling
connections). If you cannot know these things, you cannot expect Dispose to
correctly close the object. If you cannot expect Dispose to close the object
you cannot expect Dispose to be a safe pattern.
Would it surprise you to know that there are many people who believe
IDisposable was a pattern that should never have been let loose? I don't
happen to agree to an extreme extent, but I do believe its one that an end
user should never be forced to directly call into and that the literal
definition is far too narrow to make the pattern really useful. It is only
useful as a pattern to formalize Close semantics for use by compilers and
frameworks; anything more stretches the usefulness of the pattern. Sadly,
the existing specified contract does not even fulfill that, even though that
is how IDisposable is usually used.
