All,

I have a class describing various actions to take against a LINQ to SQL
datasource. What are the pros/cons of instantiating the LINQ object either
in the root of the class (for lack of a better description) or within each
of the methods? I am naturally drawn to instantiating the LINQ object in the
root but some examples I've seen preffer to keep this local to the methods.
Is there a compelling reason for this? It seems that garbage collection
would work the same for either approach but with less overhead instantiating
in the 'root' (at least to my relatively novice eye).


//instantiate in 'root' of class - this approach feels less wasteful
public class myDB
{
private myLINQObject db = new myLINQObject();

public void action1(){for i in db.tbl1...}
public void action2(){for i in db.tbl2...}
}

//instantiate in methods - seems like a lot of repetition when I know the
object will be needed anyway
public class myDB
{
public void action1()
{myLINQObject db = new myLINQObject();
for i in db.tbl1...}

public void action2(){
myLINQObject db = new myLINQObject();
for i in db.tbl2...}
}


Many thanks
n

if you keep the linq object as a private field, when is dispose called (you
forgot in your sample code)? did you implement IDispose in you db class and
call dispose on the linq object? you are moving the responsibility to the
caller to call dispose on the dbclass. are the undisposed objects (unmanaged
memory) being keep too long? better to release resources as soon as possible.

// dispose as soon as possible:

public void action1()
{
using(myLINQObject db = new myLINQObject())
{
for i in db.tbl1...
}
}


-- bruce (sqlwork.com)


"Neil Chambers" wrote:

> All,
>
> I have a class describing various actions to take against a LINQ to SQL
> datasource. What are the pros/cons of instantiating the LINQ object either
> in the root of the class (for lack of a better description) or within each
> of the methods? I am naturally drawn to instantiating the LINQ object in the
> root but some examples I've seen preffer to keep this local to the methods.
> Is there a compelling reason for this? It seems that garbage collection
> would work the same for either approach but with less overhead instantiating
> in the 'root' (at least to my relatively novice eye).
>
>
> //instantiate in 'root' of class - this approach feels less wasteful
> public class myDB
> {
> private myLINQObject db = new myLINQObject();
>
> public void action1(){for i in db.tbl1...}
> public void action2(){for i in db.tbl2...}
> }
>
> //instantiate in methods - seems like a lot of repetition when I know the
> object will be needed anyway
> public class myDB
> {
> public void action1()
> {myLINQObject db = new myLINQObject();
> for i in db.tbl1...}
>
> public void action2(){
> myLINQObject db = new myLINQObject();
> for i in db.tbl2...}
> }
>
>
> Many thanks
> n
>
>

Bruce,

Thanks for the insight.

I went about making some changes to implement using(){} automatic disposal
and was surprised by some of the results. Specifically, returning a LINQ
DataContext result to a page control didn't work. I got errors about the
object being disposed before it was used. This is actually a feature of the
LINQ DataContext - the connection/query etc is only actioned when the
results are interrogated. A few searches later I landed on this post:

http://weblogs.asp.net/stephenwalthe...-or-don-t.aspx

It would appear that calling dispose on the DataContext itself to free up
the database connection is not actually required - it's handled
automatically. Neato!

All that's left is the memory reference to the DataContext which will get
collected at some point anyway - should I worry about this? I guess that is
dependent on the amount of resources I have available.

Thanks again!

n

"bruce barker" <(E-Mail Removed)> wrote in message
news:507E308C-B1BD-46DF-9213-(E-Mail Removed)...
> if you keep the linq object as a private field, when is dispose called
> (you
> forgot in your sample code)? did you implement IDispose in you db class
> and
> call dispose on the linq object? you are moving the responsibility to the
> caller to call dispose on the dbclass. are the undisposed objects
> (unmanaged
> memory) being keep too long? better to release resources as soon as
> possible.
>
> // dispose as soon as possible:
>
> public void action1()
> {
> using(myLINQObject db = new myLINQObject())
> {
> for i in db.tbl1...
> }
> }
>
>
> -- bruce (sqlwork.com)
>
>
> "Neil Chambers" wrote:
>
>> All,
>>
>> I have a class describing various actions to take against a LINQ to SQL
>> datasource. What are the pros/cons of instantiating the LINQ object
>> either
>> in the root of the class (for lack of a better description) or within
>> each
>> of the methods? I am naturally drawn to instantiating the LINQ object in
>> the
>> root but some examples I've seen preffer to keep this local to the
>> methods.
>> Is there a compelling reason for this? It seems that garbage collection
>> would work the same for either approach but with less overhead
>> instantiating
>> in the 'root' (at least to my relatively novice eye).
>>
>>
>> //instantiate in 'root' of class - this approach feels less wasteful
>> public class myDB
>> {
>> private myLINQObject db = new myLINQObject();
>>
>> public void action1(){for i in db.tbl1...}
>> public void action2(){for i in db.tbl2...}
>> }
>>
>> //instantiate in methods - seems like a lot of repetition when I know the
>> object will be needed anyway
>> public class myDB
>> {
>> public void action1()
>> {myLINQObject db = new myLINQObject();
>> for i in db.tbl1...}
>>
>> public void action2(){
>> myLINQObject db = new myLINQObject();
>> for i in db.tbl2...}
>> }
>>
>>
>> Many thanks
>> n
>>
>>