I have seen the oddest thing on the internet as of late (yes, this is old news and the arguments are over, but I have been busy).
The Linq Datacontext very specifically inherits from IDisposable. Coding to an interface, if an object exposes Dispose, we call it. End of story.
This is actually pretty easy, as all that is required is wrapping your object up in a try/catch/finally or in a using block and its all handled for us relatively painlessly.
Then along comes MVC, for anyone not familiar with MVC, go read about it, then come back if you wish and finish this post. Or not. This Disposable pattern doesn't fit nicely into MVC... Actually, let me back up and touch on that a bit more. The Disposable pattern doesn't fit well with MVC when you are leaking the IQueryable interface into your UI.
This sounds like a non-issue to all of us out here that have been working hard to write code correctly, get better everyday, follow patterns and practices etc, so what's the deal?
The odd thing I mentioned earlier is that the ASP.NET MVC team, employeed at Microsoft, the people who many feel are the best minds working in the grand ole field that is the web, is telling us to blow all that good code away, it doesn't do us anything but cause us pain.
All of the sample code and the 'recommendations' for their repositories leak IQueryable to the UI. Besides being totally anti everything we have been trying to accomplish *as an industry* for the last 5 years (get data querying code in the correct tiers), it also means that when you take advantage of this implementation leak and actually write a query in your UI (really?), if your data context has been disposed, you get an error. Let us recap that. If you do what you aren't supposed to do, you get an error.
Sounds simple enough. The solution, don't expose implemenation specific to LINQ. No? What? The answer we are being given is to...not dispose of our datacontext. These mavericks of the web are telling us that the SQL data context doesn't manage the actual database connection and therefore doesn't manage any unmanaged resources and it doesn't matter if we don't dispose it.
While, from an implementation standpoint, this is technically true, we are being told by the company that has had to deal more with backwards compatability, has pain more in lines of code, time and money than *anyone* else by having to support breaking changes where people coded to the implementation of their APIs instead of the interface. You would *think*, these people, of *all* people would be the *last* to recommend we do the same now. And show it in all of their sample code for MVC.
I mean, really?
What is even worse is you don't even need to worry about disposable, you can still dispose of your datacontext properly and leak your magical interface.
Controller Dispose -> Repository Dispose -> DataContext Dispose
If you have to leak your magic query interface instead of creating another method or two in your repository, at least do that...