Nuclear energy is powerful too, but Marie Curie died from radiation
poisoning.
The word "powerful" is a bit overused. Perhaps "useful in certain ways for
certain types of things" would be more appropriate. Whenever I hear the
words "design pattern" or "singleton" these days I'm usually hearing some
sort of programming pop terminology, which most people that use it don't
understand the meaning of. I prefer to speak plainly, and in my own words.
After all, if one can't talk about something in your own words, what can one
know about it? What terminology one uses is not nearly as important as what
one understands. As Uncle Chutney sez, "Neither a follower nor a lender be."
;-)
Where on earth did this trend among .Net developers to want to think and
talk like Java developers come from anyway? .Net is superior to Java. Let
the Java developers learn something from Microsoft for a change!
I'm not going to talk about "singletons" or "design patterns." I don't see a
reference to a "singleton" in your code. I DO see the "static" modifier,
however, and that means what it means, no need to jazz it up with pop lingo.
A static class or member of a class is not instantiated. Instantiation is
the process of creating a copy of code and placing it on the programming
heap. This means that every instance of a class or a member of a class that
is NOT static is unique. Every time you create a "new" instance, you are
creating "another" instance in memory.
The programming heap is where code is loaded. When something is declared
static, it remains in the heap. All references to it point to the same
"instance" (if you will). Hence, the pop term "singleton." There is only
one. So, basically everyone is using the same instance. And that is not what
you want, is it? You want everyone to have their own unique instance of a
"User" class. And that means that, in this case, static is bad, m'kay?
Now that you understand what static is, you may find it useful from time to
time. It can save memory and processor, and in certain cases, quite a bit of
it. But use it correctly, or your program might end up with cancer!
--
HTH,
Kevin Spencer
Microsoft MVP
..Net Developer
Ambiguity has a certain quality to it.
Mikael Östberg said:
Kevin,
I can get rid of the static stuff, but I need to know what happended and
why. I'm not going to change not knowing why.
The singleton is a powerful pattern and I've been using it in other places
with no problems, why is it such a bad idea here?
Here's my implemetation:
private static volatile User user = null;
private static object sync = new object();
private static User Instance {
get {
if (user == null) {
lock(sync) {
if(user == null) {
user = new User();
}
}
}
return user;
}
}
Thanks!
::m
Kevin Spencer said:
Get rid of the static stuff and you should be fine. Use instances.
--
HTH,
Kevin Spencer
Microsoft MVP
.Net Developer
Ambiguity has a certain quality to it.
Mikael Östberg said:
Seriously, I have no clue.
Regarding Session, I guess I'm still in the ASP 3.0 world.
I needed some persistance between requests and made this:
/// <summary>
/// Add the <c>User</c> object to Session.
/// </summary>
/// <param name="u">An instance of an <c>User</c> object</param>
private static void StoreInSession(User u) {
HttpContext.Current.Session.Add("gameUser", u);
}
/// <summary>
/// Retrieves the <c>User</c> object from Session.
/// </summary>
/// <returns><c>User</c> object</returns>
private static User RetrieveFromSession() {
return (User)HttpContext.Current.Session["gameUser"];
}
/// <summary>
/// Removes the <c>User</c> object from the Session.
/// </summary>
private static void RemoveFromSession() {
HttpContext.Current.Session.Remove("gameUser");
}
Are you using in-Process Sessions?
--
HTH,
Kevin Spencer
Microsoft MVP
.Net Developer
Ambiguity has a certain quality to it.
Hello all!
I have this login function which doesn't work really well.
I tried to do extend the built-in functionality in order to store
things such as userName and email address in Session.
I have this User class which contains some public properties and a
number of static methods. The class implements the singelton pattern,
which allows a caller to always invoke methods of the User without
creating an instance first. That is what I think might cause the
problem.
When a user logs in, I stores the created user object in Session in
order to be able to retrieve stuff from it.
When I need access to that user object I use this method:
public static User Current {
get {
User u = RetrieveFromSession();
if (u != null) {
return u;
}
}
}
For some reason, sometimes my user "trade" session with each other.
Why is this?
User1 navigates between a couple of pages and suddenly, he is someone
else.
Thankful for help..
::m