Is this OK?

[Stevie_mac]

Hi all, quick question - I need a bit of clarity.

If I have a public class with only Public Shared functions in it, in an APS.NET web app (for common procedures) is it
safe (since multiple web pages, can at any time access the code within)

The reason for a Shared class like this is that, it would contain all of the useful functions we put together over time
like FillList, SelectListItem, FindLastItemInList, EmptyList, SortList etc etc etc

Example below - a simple routine that fills a dropdownlist. Would it be safe being accessed at multiple times by
the APSX pages? Forget the fact the code might not be perfect - only that I would like to arrange my code this way.

I suspect there may be caveats - but I need a more knowledgeable opinion.

Public Class MyUtils
Public Shared Function FillList(ByVal objList As DropDownList, ByVal sSql As String, ByVal sConnection As String) As
Boolean
Dim dr As OleDb.OleDbDataReader, Li As ListItem
Dim cn As New OleDb.OleDbConnection(sConnection)
Dim cmd As OleDb.OleDbCommand
Try
cn.Open()
cmd = New OleDb.OleDbCommand(sSql, cn)
dr = cmd.ExecuteReader(CommandBehavior.CloseConnection)
While dr.Read
Li = New ListItem
Li.Text = dr(0)
Li.Value = dr(1)
objList.Items.Add(Li)
End While
Catch ex As Exception
Stop
Return False
Finally
cmd.Dispose()
If dr Is Nothing = False Then dr.Close()
cn.Close()
End Try
Return True
End Function

Public Function EmptyList(...)
...
End Function

...
...
'Other Public Shared Functions...
...
...
End Class

Usage...
FillList(cmbListOfNames, AppSettings("SQL.PEOPLE"),AppSettings("CONSTRING.MANAGEMENT"))

 

[Jamie Dulaney]

Just a suggestion (everyone has their own ways of accomplishing things)...
But, one option would be to have that particular class inherit the standard
'Web.UI.Page' class. For example, your class could be called 'PageBase' and
look like the following:

public class PageBase : System.Web.UI.Page
{

......

}

Put all of your common routines (methods) and (properties) in this
particular class. Then, when you want to create a new webform simply
inherit this class instead of of the normal 'System.Web.UI.Page' class (the
default that gets setup for you with Visual Studio is to inherit from the
Web.UI.Page class, after it does that simply put in your own class). For
example:

public class DealerLinksList : myNameSpace.PageBase

{

....
}

You can make these methods 'protected' within your 'PageBase' class. Every
webform you create from that class will have access to these common methods
and procedures without instantiating different objects/etc. Again, you may
get 30 people responding and 30 different methods.. I like this particular
method because it provides me with an OO type capability (inheritence) and
changes can simply be made to the 'parent' class and only those members that
directly inherit from that parent class are affected...

Hi all, quick question - I need a bit of clarity.

If I have a public class with only Public Shared functions in it, in an

APS.NET web app (for common procedures) is it

safe (since multiple web pages, can at any time access the code within)

The reason for a Shared class like this is that, it would contain all of

the useful functions we put together over time

like FillList, SelectListItem, FindLastItemInList, EmptyList, SortList etc etc etc

Example below - a simple routine that fills a dropdownlist. Would it be

safe being accessed at multiple times by

the APSX pages? Forget the fact the code might not be perfect - only that

I would like to arrange my code this way.

I suspect there may be caveats - but I need a more knowledgeable opinion.

Public Class MyUtils
Public Shared Function FillList(ByVal objList As DropDownList, ByVal

sSql As String, ByVal sConnection As String) As

 

[Kevin Spencer]

Looks good to me. Just the sort of helper function you might want to use in
a variety of apps without necessarily instantiating an object to do it.

--
HTH,
Kevin Spencer
..Net Developer
Microsoft MVP
Big things are made up
of lots of little things.

Hi all, quick question - I need a bit of clarity.

If I have a public class with only Public Shared functions in it, in an

APS.NET web app (for common procedures) is it

safe (since multiple web pages, can at any time access the code within)

The reason for a Shared class like this is that, it would contain all of

the useful functions we put together over time

like FillList, SelectListItem, FindLastItemInList, EmptyList, SortList etc etc etc

Example below - a simple routine that fills a dropdownlist. Would it be

safe being accessed at multiple times by

the APSX pages? Forget the fact the code might not be perfect - only that

I would like to arrange my code this way.

I suspect there may be caveats - but I need a more knowledgeable opinion.

Public Class MyUtils
Public Shared Function FillList(ByVal objList As DropDownList, ByVal

sSql As String, ByVal sConnection As String) As

 

[Jim Corey]

Well, this might not directly be the answer you're looking for, but...
This looks like routines I've seen that are used populate dropdowns in
original ASP. If you are coming from ASP you may want to resist using
your experiences in ASP.NET.
I think that you'll find yourself binding datasources to dropdowns
rather than populating them this way.

I do have instances where I pass a dropdown to a shared function, and it
works fine, but this is for a specific
business purpose and not for generic processing.

Jim

 

[mikeb]

Hi all, quick question - I need a bit of clarity.

If I have a public class with only Public Shared functions in it, in an APS.NET web app (for common procedures) is it
safe (since multiple web pages, can at any time access the code within)

The reason for a Shared class like this is that, it would contain all of the useful functions we put together over time
like FillList, SelectListItem, FindLastItemInList, EmptyList, SortList etc etc etc

Example below - a simple routine that fills a dropdownlist. Would it be safe being accessed at multiple times by
the APSX pages? Forget the fact the code might not be perfect - only that I would like to arrange my code this way.

As long as the shared functions do not modify shared data, then having
multiple ASPX pages use the functions concurrently should pose no problem.

If they do access shared data (and it's going to be modified), then
you'd need to protect access to the shared data using a Monitor object
(the SyncLock statement in VB.NET or the lock keyword in C#).

It looks like the sample routine you provided should have no problems
with concurrent use.

 

[Stevie_mac]

Thanks every one for taking the rime to respond.

All your answers were in part, the whole answer i was looking for.

My main concern was not fully unsderstanding VB shared - was cleared up nicely by mikeb
<quote>
If they do access shared data (and it's going to be modified), then
you'd need to protect access to the shared data using a Monitor object
(the SyncLock statement in VB.NET or the lock keyword in C#).
</quote>

but equally, there was some good ideas in the others

Yes data binding is 'the way' (i do do it some if Im coding for myself) but there is times when you need to loop it!

As for inheriting my own 'webpage' with protected members - this is a good idea & more OOP solution, however, one would
have to modify existing code rather than *modify* (sounds like my current role - 'The modifier') ;-) But I do agree,
this is probably the better solution if starting a new.

 

[Cor Ligthert]

Hi MikeB

Stevie answered me in another newsgroup on my question why his class should
be shared, that you told him with that this was OK. Which for me also
implements the best way to go.

His class contents as far as I can see only everytime new build objects or
uses objects which are given to the procedure by reference or value.

Therefore I do not understand it why it is OK (the best way to go) to do
that in a shared class, maybe you can explain it for me?

Or do you mean it will run and most probably give no errors?

Cor

 

[Stevie_mac]

Hello again Cor,
In our other thread, I was a bit off your track of thought, I understand now why you question this...

The use of share class VS instantiating an object is (almost) completely a matter of programmatic simplicity. I do agree
that a class with members that are created once & reused is the most obvious choice - in most cases, however, in ASP.NET
(web) programming, every call to a page is a new object anyway (yes I could use Session but nature of the work I'm doing
means the users would suffer timeouts). Not to say that the structure of what I'm currently working on couldn't be
arranged so that the use on instantiated classes with member variables stored Session was viable (I.E. previous input
was stored in Viewstate & Session objects rebuilt from it when timed out) but there are arguments against this.

Besides, that function (one of quite a few) was probably the worst example! most of the functions would be rather benign
(like Empty, FindInListByValue, Shortlist)

Anyway, my initial question was really to better understand VB Shared key word, which I now do.

Thanks again, stevie_mac

 

[mikeb]

Hi MikeB

Stevie answered me in another newsgroup on my question why his class should
be shared, that you told him with that this was OK. Which for me also
implements the best way to go.

If I recall correctly, I was focusing on stevie_mac's question about the
*safety* of a shared method being accessed by multiple ASPX pages. I
really didn't look at whether his routine should be shared versus being
an instance method.

As far as the 'best' way to go, I think I'd agree with Jim Corey's
response that stevie_mac should look at databinding.

His class contents as far as I can see only everytime new build objects or
uses objects which are given to the procedure by reference or value.

Therefore I do not understand it why it is OK (the best way to go) to do
that in a shared class, maybe you can explain it for me?

The difference between a shared method and an instance method is that a
shared method does not get an implicit object instance to work on - it
can only work on the items passed to it in the parameter list or on
shared data that also does not belong to an object instance.

Some of the times that you might want to use shared methods are:

1) you want to have a method work on an existing class, but the
class is sealed so you can't derive a new class from it. You see this
type of shared method all the time for handling strings.

2) you want a method that can deal with objects of various classes
that might not be in the same hierarchy. The Convert class is an example
of this.

3) you want a factory method that creates or finds an object
instance and returns it (like the Singleton pattern).