when to use shared variables - asp.net

Question

I have built a class which is instantiated many times in a list using vb.net. I want to persist an ID across all instantiations of my class. It's a list of questions which will all have one questionnaire ID. So I can do this whilst assigning the id to each question in the list. Ideally I would like to just assign the ID once and have it available in all the list objects.
So here is my shared member of a class along with property procedure for accessibilty.
Public Class Questions
Private Shared _questionnaireUID As Integer
Public Shared Property QuestionnaireUID() As Integer
Get
Return _questionnaireUid
End Get
Set(ByVal value As Integer)
_questionnaireUid = value
End Set
End Property
End Class
I started to use a vb.net shared class level variable and assigned through a property procedure. This seemed like the right approach, although now I have built it I can see that the shared variable is accessible throughout the entire application.
So like this for instantiation and assignment.
Questions.QuestionnaireUID = CInt(questionnaireUID)
I dont even need to instantiate the class. So I now just have a global variable. to get around this I would use a class level variable instead of. I wondered if there is another way to just make the variable shared across the class and it's instantiated objects without assigning to each object and without making it available across the entire application. Is there a step I am missing.
Thanks for any advice.

Answer 1

I am C# but that is not how I would go about it.
Have a class for the questionnaire
public class Questionnaire
{
public Int ID { get; private set; }
public List<Question> Questions { get; set; }
}

Answer 2

I think a shared (static) is really useful if you want to share something in the whole application.
If I understand you right, you indeed have a class and would like to share one ID, but this ID is not interesting for the whole application but only for a questionnaire (a list of questions). For this, using shared is bad, because you will have to take care of the cleaning of this value once you're finished.
My question is, why do you instantiate the question list every time that you have a new question? Why don't putting the question list as a singleton?

Answer 3

Just because the private field is Shared, that does not mean that the property that accesses it also has to be Shared. For instance, you could do this:
Public Class Questions
Private Shared _questionnaireUID As Integer
Public Property QuestionnaireUID() As Integer ' Note, this is not Shared
Get
Return _questionnaireUid
End Get
Set(ByVal value As Integer)
_questionnaireUid = value
End Set
End Property
End Class
When you do that, all Questions objects will always share the same value for that property, but the value will not be accessible through the class (without instantiating an object).
However, it's worth pointing out that, while that does encapsulate the value a little better as far as scope is concerned, it's still global state. It doesn't really avoid most of the problems which are caused by having global variables. The objects of that class will still behave in potentially unpredictable ways just as with any other kind of global state. It also makes it so that you cannot have Questions objects working on two different ID's at the same time.
As an alternative, you may want to look into injecting the ID in the Questions class' constructor. If passing it in each time you create one is too much of a pain, you could make it easier with a factory, for instance:
Public Class QuestionsFactory
Public Sub New(questionnaireId As Integer)
_questionnaireId = questionnaireId
End Sub
Private _questionnaireId As Integer
Public Function NewQuestions() As Questions
Return New Questions(_questionnaireId)
End Function
End Class