Why not use static/shared methods?

I'm a fan of static functions. I think they are particularly well suited in
the case of asp.net where the general lifetime of objects is a single page
view (except for objects placed in the viewstate, session, application
scope). I think in the case of your DAL, this is particularly true.

A couple points:
-If you look at IBuySpy (microsoft's best approach guideline), you'll see
that their DAL is not implemented using static methods -though there has
been dicussion on this, and I've always seen a majority of people agree that
static methods would be ideal.
-It should be noted, as far as I know, vb.net methods are limited to 32
parameters...this could prove to be a problem with your shared methods,
whereas with an instance of an object you could set well over 32 properties
(this maybe a scenario for advanced searches?).
-Static methods have less overhead and are quicker

I'd do it using static methods...the person actually writing our DAL has
decided to use instance methods...i think the fact that we don't have a
standard is a bigger problem than doing it one way vs another.

Karl

<DanR@dotnet.itags.org.REMOVETHISTOGETTOME-warshawgroup.com> wrote in message
news:uitzjsIRDHA.2676@dotnet.itags.org.TK2MSFTNGP10.phx.gbl...
> When I implement my DB classes/DAL layer, why shouldn't I make the methods
> (in VB) 'shared'?
> Forget the other questions I have right now about whether to put in that
> finally block, etc. Why not make the function shared? Why bother have the
> class be instatiated and then the method invoked- this method could be
> shared, it really has no state, right?
> -Dan R
>
> For example, let's say I've got the following method of the DAL class
> (you've seen something like this)
> Public Function GetSqlDataReader(ByVal strSQL As String) As SqlDataReader
> Dim con As SqlConnection = New
SqlConnection(DBAccess.SQL_CONN_STR)
> Dim cmd As SqlCommand = New SqlCommand(strSQL, con)
> Dim dr As SqlDataReader
> Try
> con.Open()
> dr = cmd.ExecuteReader(CommandBehavior.CloseConnection) 'We do
> this so that a .close on the SqlDataReader will close the connection.
> Return dr
> Catch ex As Exception
> Throw ex 'Rethrows it. I don't need to put the ex, I don't
> think, incidentally
> Finally 'From
> http://www.dotnet247.com/247reference/msgs/8/40569.aspx is this overkill?
> If (Not dr Is Nothing) Then 'It was left open
> dr.Close()
> End If
> End Try
> End FunctionI was worried about threading issues if the class had static methods- that
two different ASP sessions could access the same static class member. That's
a bit confusing to me- I wasn't sure if I would have to use a mutex or
something in Static methods to ensure their thread safety. Can anyone who
knows what I'm talking about tell me what it is that I'm talking about? :)

"Karl Seguin" <kseguin##crea.ca> wrote in message
news:OReGV3IRDHA.2424@.tk2msftngp13.phx.gbl...
> I'm a fan of static functions. I think they are particularly well suited
in
> the case of asp.net where the general lifetime of objects is a single page
> view (except for objects placed in the viewstate, session, application
> scope). I think in the case of your DAL, this is particularly true.
> A couple points:
> -If you look at IBuySpy (microsoft's best approach guideline), you'll see
> that their DAL is not implemented using static methods -though there has
> been dicussion on this, and I've always seen a majority of people agree
that
> static methods would be ideal.
> -It should be noted, as far as I know, vb.net methods are limited to 32
> parameters...this could prove to be a problem with your shared methods,
> whereas with an instance of an object you could set well over 32
properties
> (this maybe a scenario for advanced searches?).
> -Static methods have less overhead and are quicker
> I'd do it using static methods...the person actually writing our DAL has
> decided to use instance methods...i think the fact that we don't have a
> standard is a bigger problem than doing it one way vs another.
> Karl
>
> <DanR@.REMOVETHISTOGETTOME-warshawgroup.com> wrote in message
> news:uitzjsIRDHA.2676@.TK2MSFTNGP10.phx.gbl...
> > When I implement my DB classes/DAL layer, why shouldn't I make the
methods
> > (in VB) 'shared'?
> > Forget the other questions I have right now about whether to put in
that
> > finally block, etc. Why not make the function shared? Why bother have
the
> > class be instatiated and then the method invoked- this method could be
> > shared, it really has no state, right?
> > -Dan R
> > For example, let's say I've got the following method of the DAL class
> > (you've seen something like this)
> > Public Function GetSqlDataReader(ByVal strSQL As String) As
SqlDataReader
> > Dim con As SqlConnection = New
> SqlConnection(DBAccess.SQL_CONN_STR)
> > Dim cmd As SqlCommand = New SqlCommand(strSQL, con)
> > Dim dr As SqlDataReader
> > Try
> > con.Open()
> > dr = cmd.ExecuteReader(CommandBehavior.CloseConnection) 'We
do
> > this so that a .close on the SqlDataReader will close the connection.
> > Return dr
> > Catch ex As Exception
> > Throw ex 'Rethrows it. I don't need to put the ex, I don't
> > think, incidentally
> > Finally 'From
> > http://www.dotnet247.com/247reference/msgs/8/40569.aspx is this
overkill?
> > If (Not dr Is Nothing) Then 'It was left open
> > dr.Close()
> > End If
> > End Try
> > End Function