Is It Bad Practice To Use Static Members In ASP.NET Website?

Question

I understand that a static member will be shared by all users of an ASP.NET website; but in this particular case - that's exactly what I want.

It's a private-use webpage I threw together to facilitate web-based chatting between two users. I wanted to avoid persisting data to a database or a datafile, and thought I could store the last X messages in a static concurrent queue. This seems to work great on my development machine.

I'm very inexperienced with ASP.NET, but in all of the examples I've found, none use this approach. Is this a bad-practice, are there 'gotchas' I should be aware of? The alternative, that I can see, is to use a database. But I felt like it would be more effort and, my guess, is more resources (I figure my 'buffer' of messages will take about 40kb of memory and save quite a few trips to the database).

score 9 · Answer 1 · answered Jun 05 '12 at 16:10

9

Assuming that you make sure that the entire thing is thread-safe, that will work.

However, IIS can recycle your AppDomain at any time, so your queue may get blow away when you don't expect it.

answered Jun 05 '12 at 16:10

SLaks

868,454
176
1,908
1,964

1

Plus you are stuck to just one server- an in-memory queue cannot really be shared across machines. – Chris Shain Jun 05 '12 at 16:14
1

+1. @ChrisShain, one need to be very chatty to require more than one server for on-to-one chat with just another person :) – Alexei Levenkov Jun 05 '12 at 16:23

Dennis Traub · Answer 2 · 2012-06-05T16:32:48.443

4

Even if IIS wouldn't flush and restart your AppDomain every now and then, using static variables for this purpose sounds like a smelly hack to me.

The HttpApplicationState class provides access to an application-wide cache you can use to store information.

ASP.NET Application State Overview

edited Jun 05 '12 at 16:32

answered Jun 05 '12 at 16:13

Dennis Traub

50,557
7
93
108

score 1 · Answer 3 · edited May 23 '17 at 12:28

1

Sure, one gotcha I've seen in the past has been the use of static variables with Web Gardens.

See this SO question: Web Garden and Static Objects difficult to understand

Note a key point from the discussion:

Static objects are not shared in web gardens/web farms.

edited May 23 '17 at 12:28

Community

1
1

answered Jun 05 '12 at 16:17

jglouie

12,523
6
48
65

score 1 · Accepted Answer · answered Jun 05 '12 at 16:36

This is perfectly fine as long as your requirements don't change and you are OK with randomly loosing all messages on server side.

I would slightly refactor code to provide "message storage" interface to simplify testing of the code (with potential benefit in the future if you decide to make it more complicated/persisted/multi-user).

Pro of the static storage approach (or HttpApplicationState):

no issues with server side storage of the messages - less privacy concerns. Nothing is stored forever so you can say whatever you want.
extremely simple implementation.
perfect for IM / phone conversation.
unlikely to have performance problems in single server case

Cons:

messages can be lost. Can be mitigated by storing history on the client (i.e. retrieving message with AJAX queries on the same web page)
require more care if data is sensitive when more users are involved/or application is shared with some other code as static data is visible to everyone. Also not much different from any other storage.
Can't be directly migrated to multiple servers/web garden scenario. Really unlikely issue for 2 person chat server.

Is It Bad Practice To Use Static Members In ASP.NET Website?

4 Answers4