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
Post a Comment