The Author Online Book Forums are Moving

The Author Online Book Forums will soon redirect to Manning's liveBook and liveVideo. All book forum content will migrate to liveBook's discussion forum and all video forum content will migrate to liveVideo. Log in to liveBook or liveVideo with your Manning credentials to join the discussion!

Thank you for your engagement in the AoF over the years! We look forward to offering you a more enhanced forum experience.

Lee Dumond (29) [Avatar] Offline
#1
Hey guys,

Don't know if I'm expressing my question properly in the topic heading, but my question relates to the debates raging among the various blogs in which folks are discussing various DataContext design patterns. Mainly, I'm wondering if there is any benefit to disposing of the DataContext after each use, or letting it hang around.

Of course, most examples and tutorials out there show creating a new DataContext for each and every unit of work.

MyDataContext context = new MyDataContext()

However, some are employing using blocks as to dispose of the context when they're finished using it:

using (MyDataContext context = new MyDataContext())
{

};

Is there any benefit to disposing of the DataContext by employing a using block, and if so, what is it? I assume creating a DataContext is a pretty lightweight task, but since they support caching, the actual DataContexts themselves can probably get somewhat heavy. This tends to lend support to the disposing argument. Or does it?

I have also seen design patterns where an "ambient" DataContext is created as a property of a class and shared by the various methods (I think you guys do that in the LinqBooks example somewhere). Are there any potential pitfalls there?
jwooley (123) [Avatar] Offline
#2
Re: Best practice for handling DataContext life cycle
Anything that implements IDisposable should be disposed explicitly by calling dispose or wrapped in a Using block. Unfortunately, many of the examples in the book failed to follow this best practice.

In a connected environment, you can hold on to the context for more than one transaction and utilize a unit of work pattern. In a disconnected (web) environment, the context should be short lived and thus you have to manage the life cycle more explicitly (with an Attach to attach objects that have been disconnected to their context). In this disconnected world, it is possible to pass around a context to various functions in the page's lifecycle. In those cases, you may need to manage the context's dispose more explicitly.

Jim
Lee Dumond (29) [Avatar] Offline
#3
Re: Best practice for handling DataContext life cycle
Hi Jim,

I'm not quite sure what you mean on that last part:

"In this disconnected world, it is possible to pass around a context to various functions in the page's lifecycle. In those cases, you may need to manage the context's dispose more explicitly."

I am working in ASP.NET here, which of course is a disconnected environment. I've got a back-end DAL. Are you saying that if I use an ambient DataContext, I should somehow manually dispose the DataContext at some point? And if so, can you provide a brief example?
jwooley (123) [Avatar] Offline
#4
Re: Best practice for handling DataContext life cycle
The traditional scenario here is where the objects have methods that fetch and update themselves, along the lines of an Active Record pattern. Rick Strahl did a series on this architecture a bit back. The downside with this approach is that you will create separate contexts for each operation. In that case, you may be able to leverage the Using block since the interaction is more atomic.

Another option would be to have the code behind the form manage the context and then pass that to the DAL for the various database interactions. In that scenario, you could create the context on form load and then dispose it at the end of the page's lifecycle. This allows for more unit of work behavior from LINQ to SQL, but is not the pattern you typically see.

Jim
Lee Dumond (29) [Avatar] Offline
#5
Re: Best practice for handling DataContext life cycle
Okay, I gotcha.

Passing the context between the UI and DAL strikes me as kinda yucky.

Actually, creating separate contexts for each method, while a bit verbose, doesn't bother me as long as I don't have a bunch of stray contexts soaking up memory for nothing.

If you do use separate DataContexts for each operation without disposing, would the normal .NET garbage collection eventually vacuum them up? Or would they hang around indefinitely? In other words, is the framework smart enough to "know" you're done using a particular context, once the method in which it is created has done its work?
ecards (1) [Avatar] Offline
#6
Re: Best practice for handling DataContext life cycle
>>If you do use separate DataContexts for each operation without disposing, would the
>>normal .NET garbage collection eventually vacuum them up?

Yes. Please see here:
http://lee.hdgreetings.com/2008/06/linq-datacontex.html

Regards,
LTG