For some reason I am not getting >s in the response, so I have surrounded
your queries with <query></query>
Is visitor data important even if the visitor never joins? If so, persist
the data when the user takes the poll and don't store it on the visitor
object.
Instead, create some type of token (GUID is fine) to represent the visitor
in the database and "persist" that to the visitor's computer in a cookie.
That way if they do not join today, and do not clear their cookies, you
might still be able to link them to their data.
<query>
But when a user visits the web site won't he be added to Users table
and IsAnonymous set to true? then I can use the UserID of the
anonymous user or not?
Yes, I know now and then I will need to delete anonymous users to
prevent the database to get to big.
Bu I could delete only anonymous users that has not accessed the web
site on the last, let's say, 4 months.
</query>
You can add an anonymous user. The problem is this only works for this
session, as the user can delete any evidence he ever visited your site if
there is no method to persist the information on his computer (cookie?) or
he deletes said cookie, if you use cookies. He then becomes a completely
different user to your application. If this information is useful, then
there is no problem, but the only information you can use from the user is
info from his latest visit. The other anonymous users created for him are
simply taking up space in your database.
And you can selectively delete users that have not revisited, if you desire.
But, as mentioned, you can have 10 visitors representing one person and
never even know it. That may be fine for you. I don't know.
The point is this. When an anonymous user hits an application that uses the
ASP.NET membership, and is set to care about individual anonymous users
(rather than grouping all under one single "account"), it identifies the
user with a cookie. If the user deletes that cookie, and returns to the
site, the application has no clue who he is and creates another account.
This is not a high risk, but it is something to keep in mind.
If the information attached to this account is useful, even if the person
never joins, then it is useful to keep it. If not, then I would not even
create an anonymous account for that user and instead store everything in
the cookie, hoping the user does not delete the cookie.
What is hard, with web apps, is it is impossible to identify a user who
cleans up after himself. The only way is to force anonymous people to create
accounts to do anything other than read on your site. Then, they have to log
in and you know who they are. A user that allows you to keep tabs on them
(via cookies) can be identified, but only as long as he allows it. The
anonymous user account works the same way. There is no guaranteed way to
link it back to a user that does not want you to do so.
My thought is there is no reason to clutter up the database with different
anonymous accounts. I would send out a cookie to the user and store info
there. Then, when the user joins, I would pull information from the cookie
when the form is submitted and put that in his profile. If the user deletes
the cookie, I lose this information, but I lose it if he deletes cookies and
there is an ASP.NET anonymous account for him, as well. I see storing a
cookie as less code and less information stored than potentially creating
numerous accounts because this user deletes his cookies regularly.
Other ways to attempt to identify an anon user fall flat. IP is only
useful
when the person has a permanent IP. Almost every service uses dynamic IPs
now, so it is unlikely the user will continue to get the same IP forever.
Although, it might be useful for short term (not sure what the average
lease
time is amongst broadband providers).
Now, back to your visitor object. Unless you are using it to draw the
polls
for the user on every page, carrying around numerous Guids is useless. You
can look up that information when the user gets to the polls page and not
take that trip before then.
<query>
What do you mean? I got lost ...
Basically, my idea is every time a user votes on a poll I add the
PollID to visitor Polls property.
When he votes in a poll I check if that PollID exists in Polls
property and display a message if it does.
This is not critical ... it it would be I would allow only registered
users to vote. It is just a way to make voting a little bit more
"fair".
</query>
In general, you are best to keep objects with information that is necessary
to identify the user (a user id for example) and information used by all, or
at least most, pages.
Culture Information is used by every page, as it helps set language, number
separators, etc. It is a good thing to use on a user object. If the polls
show up on every page, it is useful to keep the list cached in an object. If
they only show up when the person hits the Poll page, then you are better to
look that information up when the user hits that page.
Hope this helps!
