471,605 Members | 1,343 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,605 software developers and data experts.

Business/Data design, IDisposable, and using statement?

I trying to determine the best pattern for designing my business and data
layers...

Can the instance of the business object eventually cause memory leaks in
Example 1? If your business class doesn't implement IDisposable and falls
out scope, does it eventually get cleaned up by the GC or should it be set to
NULL?

If it can cause leaks, should the IDisposable always be implemented at a
base class level as a best practice?

If it does implement IDisposable, is wrapping the using statement (Example
2) in a try block to catch any exceptions the proper technique? I see
samples of "using" but not many of how to handle an exception if it occurs in
the using block.

EXAMPLE 1
-------------
MyBizClass myBizClass = null;
try
{
myBizClass = new MyBizClass();
return myBizClass.GetSomeDataFromDataLayer();
}
catch
{
throw;
}
finally
{
//Set myBizClass = null???
}

EXAMPLE 2
--------------

try
{
using (MyBizClass myBizClass = new MyBizClass())
{
return myBizClass.GetSomeDataFromDataLayer();
}
}
catch
{
throw;
}


Feb 1 '06 #1
3 3407
Dave,

You should use IDisposable only when you have the need for controlling
the lifetime of an object, most likely as the result of using a resource
which can not just be left in an undisposed state (such as a file handle,
unmanaged memory, a database handle, etc, etc).

I also use IDisposable on structures when I want to have deterministic
finalization semantics in a method.

Your class doesn't seem to be doing either, so I would not implement
IDisposable. Also, setting a variable to null (not a field, a variable)
will actually prolong the lifetime of the object in code compiled for
release mode.

Hope this helps.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"Dave" <Da**@discussions.microsoft.com> wrote in message
news:E6**********************************@microsof t.com...
I trying to determine the best pattern for designing my business and data
layers...

Can the instance of the business object eventually cause memory leaks in
Example 1? If your business class doesn't implement IDisposable and falls
out scope, does it eventually get cleaned up by the GC or should it be set
to
NULL?

If it can cause leaks, should the IDisposable always be implemented at a
base class level as a best practice?

If it does implement IDisposable, is wrapping the using statement (Example
2) in a try block to catch any exceptions the proper technique? I see
samples of "using" but not many of how to handle an exception if it occurs
in
the using block.

EXAMPLE 1
-------------
MyBizClass myBizClass = null;
try
{
myBizClass = new MyBizClass();
return myBizClass.GetSomeDataFromDataLayer();
}
catch
{
throw;
}
finally
{
//Set myBizClass = null???
}

EXAMPLE 2
--------------

try
{
using (MyBizClass myBizClass = new MyBizClass())
{
return myBizClass.GetSomeDataFromDataLayer();
}
}
catch
{
throw;
}

Feb 1 '06 #2
"Dave" <Da**@discussions.microsoft.com> wrote in message news:E6**********************************@microsof t.com...
I trying to determine the best pattern for designing my business and data
layers...
Oki. And it seems like you think you must try... and catch..

Can the instance of the business object eventually cause memory leaks in
Example 1? If your business class doesn't implement IDisposable and falls
out scope, does it eventually get cleaned up by the GC or should it be set to
NULL?
It will be cleaned up by the GC. At some time... In seconds, hour or days...
Why IDisposable is sometimes important. As for sql connections or filehandles.

If you open a file for writing, you can't wait for the GC to (maybe) kick in and remove the filehandle in the destructor (finalizer) of the object. The file will be locked until the stream is collected.
If it can cause leaks, should the IDisposable always be implemented at a
base class level as a best practice?
Your objects typically won't leak. Only if you start allocating resources that must (should) be disposed of after its direct use you should implement IDsposable.

Hence, If you have a class that sports the metod save, and that opens a stream, writes and call .Dispose() you should not implement IDisposable yourself.

But, if you create a class with the methods Open(string filename), Write(string stuff) and Close(), you should implement IDisposable.
EXAMPLE 1
-------------
This does nothing. catching and throwing does what?
And as your ? says in your finally comment. What should it do?

You're doing nothing with your try, catch, finally..
Just rewrite it into:

public SomeData DoStuff()
{
MyBizClass myBizClass = new MyBizClass();
return myBizClass.GetSomeDataFromDataLayer();
}
EXAMPLE 2
--------------


You think you have to implement IDisposable. Well you don't.
So don't focus on the caller, let's have a look att the method being called...

it should look something like this:

public SomeData GetSomeDataFromDataLayer();
{
using (SqlConnection conn = SomeConnectionFactory.Create())
{
//etc etc
}
}

SqlConnection implements IDisposable, and by using the using syntactic suggar, you have actually done something like this:

public SomeData GetSomeDataFromDataLayer();
{
Try
{
SqlConnection conn = SomeConnectionFactory.Create())
//etc etc
}
finally
{
conn.Dispose(); // no matter what, the sql connection will be returned to the pool.
}
}

Hope this makes it clearer for you.

Happy Coding
- Michael S
Feb 1 '06 #3
A simple set of rules for when you need to implement IDisposable is:

1-the common one) If your class owns any object that implements IDisposable
then it must implement IDisposable and Dispose must call Dispose on those
objects.

2-the less common one) If you your class holds any "handle" to a resource
obtained by some interop call then you must implement IDisposable to release
that resource. [You should write a class whose sole purpose it to own that
handle and to wrap the interop calls associated with it.]

3) If some object gives you a handle then see 2 - but this should never
happen because the design sucks.

"Dave" <Da**@discussions.microsoft.com> wrote in message
news:E6**********************************@microsof t.com...
I trying to determine the best pattern for designing my business and data
layers...

Can the instance of the business object eventually cause memory leaks in
Example 1? If your business class doesn't implement IDisposable and falls
out scope, does it eventually get cleaned up by the GC or should it be set
to
NULL?

If it can cause leaks, should the IDisposable always be implemented at a
base class level as a best practice?

If it does implement IDisposable, is wrapping the using statement (Example
2) in a try block to catch any exceptions the proper technique? I see
samples of "using" but not many of how to handle an exception if it occurs
in
the using block.

EXAMPLE 1
-------------
MyBizClass myBizClass = null;
try
{
myBizClass = new MyBizClass();
return myBizClass.GetSomeDataFromDataLayer();
}
catch
{
throw;
}
finally
{
//Set myBizClass = null???
}

EXAMPLE 2
--------------

try
{
using (MyBizClass myBizClass = new MyBizClass())
{
return myBizClass.GetSomeDataFromDataLayer();
}
}
catch
{
throw;
}

Feb 2 '06 #4

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

9 posts views Thread by Hasan O. Zavalsiz | last post: by
5 posts views Thread by Robert Heuvel | last post: by
18 posts views Thread by D Witherspoon | last post: by
12 posts views Thread by Cordell Lawrence \(News Group\) | last post: by
25 posts views Thread by Penelope Dramas | last post: by
1 post views Thread by XIAOLAOHU | last post: by
reply views Thread by MichaelMortimer | last post: by
reply views Thread by CCCYYYY | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.