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


i understand static member shared users of asp.net website; in particular case - that's want.

it's private-use webpage threw facilitate web-based chatting between 2 users. wanted avoid persisting data database or datafile, , thought store last x messages in static concurrent queue. seems work great on development machine.

i'm inexperienced asp.net, in of examples i've found, none use approach. bad-practice, there 'gotchas' should aware of? alternative, can see, use database. felt more effort and, guess, more resources (i figure 'buffer' of messages take 40kb of memory , save quite few trips database).

this fine long requirements don't change , ok randomly loosing messages on server side.

i refactor code provide "message storage" interface simplify testing of code (with potential benefit in future if decide make more complicated/persisted/multi-user).

pro of static storage approach (or httpapplicationstate):

  • no issues server side storage of messages - less privacy concerns. nothing stored forever can whatever want.
  • extremely simple implementation.
  • perfect im / phone conversation.
  • unlikely have performance problems in single server case

cons:

  • messages can lost. can mitigated storing history on client (i.e. retrieving message ajax queries on same web page)
  • require more care if data sensitive when more users involved/or application shared other code static data visible everyone. not different other storage.
  • can't directly migrated multiple servers/web garden scenario. unlikely issue 2 person chat server.

Comments

Popular posts from this blog

java - Play! framework 2.0: How to display multiple image? -

gmail - Is there any documentation for read-only access to the Google Contacts API? -

php - Controller/JToolBar not working in Joomla 2.5 -