Professional Web Applications Themes

Why not use static/shared methods? - ASP.NET General

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, ...

  1. #1

    Default Re: 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



    <DanRREMOVETHISTOGETTOME-warshawgroup.com> wrote in message
    news:uitzjsIRDHA.2676TK2MSFTNGP10.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
    > [url]http://www.dotnet247.com/247reference/msgs/8/40569.aspx[/url] is this overkill?
    > If (Not dr Is Nothing) Then 'It was left open
    > dr.Close()
    > End If
    > End Try
    > End Function
    >
    >

    Karl Seguin Guest

  2. #2

    Default Re: Why not use static/shared methods in my DAL?

    I 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.2424tk2msftngp13.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
    >
    >
    >
    > <DanRREMOVETHISTOGETTOME-warshawgroup.com> wrote in message
    > news:uitzjsIRDHA.2676TK2MSFTNGP10.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
    > > [url]http://www.dotnet247.com/247reference/msgs/8/40569.aspx[/url] is this
    overkill?
    > > If (Not dr Is Nothing) Then 'It was left open
    > > dr.Close()
    > > End If
    > > End Try
    > > End Function
    > >
    > >
    >
    >

    Guest

Similar Threads

  1. Replies: 2
    Last Post: December 3rd, 12:47 AM
  2. #39177 [NEW]: Need mechanism to identifed calling class in static methods
    By acarheden at gmail dot com in forum PHP Bugs
    Replies: 1
    Last Post: November 11th, 01:34 AM
  3. Replies: 3
    Last Post: October 5th, 03:04 PM
  4. Replies: 1
    Last Post: September 11th, 09:21 PM
  5. Static shared data connection provider?
    By Jon Davis in forum ASP.NET Data Grid Control
    Replies: 7
    Last Post: April 6th, 01:48 AM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139