CODEWITHSUNDEEP
c#asp.net
Rob P.
Rob P.

Reputation: 15091

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

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).

Upvotes: 2

Views: 918

Answers (4)

Alexei Levenkov
Alexei Levenkov

Reputation: 100620

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.

Upvotes: 1

Dennis Traub
Dennis Traub

Reputation: 51684

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

Upvotes: 4

jglouie
jglouie

Reputation: 12880

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.

Upvotes: 1

SLaks
SLaks

Reputation: 888205

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.

Upvotes: 9

Related Questions