How do I implement an ASP.NET cross-session data controller class? -

i creating asp.net application allows users edit , insert data persisted in sql server database. implement controller class handles queries entities, caches results , triggers events when data inserted or updated. need 1 of these controller classes each entity in data model. i'm unsure of how create singleton class of sort different user sessions can access.

for example, have employee entity in data model. have employeecontroller class handles retrieving employees database, sends inserts , updates database, keeps cache of employees , triggers events when employee inserted or updated. objects in other user sessions listen , respond these events.

so:

• am on right track?
• should using asp.net mvc framework accomplish this?
• how instantiate these controller classes when first user needs them , have subsequent concurrent users access same class?

edit:

i've been researching idea of controller class anti-pattern since @tomtom's answer. i'm not convinced 1 way or other.

i still need answer question #3 above. let's drop specific idea of controller class now. how create any class is:

1. accessible multiple user sessions,
2. allows 1 instance,
3. is deleted if there no user sessions, ,
4. triggers events other classes can listen to.

first of all, term "controller" used in mvc, , indeed c in mvc. don't want confuse two.

what describing more repository pattern, although without singleton nature. it's possible, using inversion of control , dependancy injection container make repositories singletons.

however, bigger problem you're going have sessions imaginary in web applications. don't exist (despite attempts frameworks make think do).

essentially, web applicaiton exists when actively connected site, , posting or getting http data. request done, app in limbo. after period of inactivity, fake session times out , there nothing, until next person connects.

so, concept of "cross session" meaningless in web application, because never know when else connected or not, whether or not can fire events other sessions, etc... huge pain in ass, error prone @ best, , disaster @ worst.

your best bet create "event" table in database each session can check everytime something. can whatever want events. remember, web stateless.