Best Practice for using LINQ object within class

[Neil Chambers]

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

[=?Utf-8?B?YnJ1Y2UgYmFya2Vy?=]

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

[Neil Chambers]

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" <br*********@discussions.microsoft.comwrote in message
news:50**********************************@microsof t.com...

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