Question

I am creating an ASP.NET application that allows users to edit and insert data that is persisted in a SQL Server database. I would like to implement a controller class that handles queries for certain entities, caches results and triggers events when data is inserted or updated. I need one of these controller classes for each entity in my data model. What I’m unsure of is how to create a singleton class of this sort that different user sessions can access.

For example, I have a Employee entity in my data model. I would like to have an EmployeeController class that handles retrieving the employees from the database, sends inserts and updates to the database, keeps a cache of all employees and triggers events when an employee is inserted or updated. Objects in other user sessions could then listen and respond to these events.

So:

• Am I on the right track?
• Should I be using the ASP.NET MVC framework to accomplish this?
• How do I instantiate these controller classes when the first user needs them and have subsequent concurrent users access the same class?

EDIT:

I’ve been researching the idea of a controller class as an anti-pattern since @TomTom’s answer. I’m not convinced one way or the other.

I still need an answer to question #3 above. Let’s just drop the specific idea of a controller class for now. How do I create any class that is:

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

Answer 1

First of all, the term “Controller” is already used in MVC, and is indeed the C in MVC. You don’t want to confuse the two.

What you are actually describing is more like the Repository pattern, although without the singleton nature. It’s certainly possible, using Inversion of Control and a Dependancy Injection container to make repositories singletons.

However, the bigger problem you’re going to have is that sessions are imaginary in web applications. They don’t really exist (despite the attempts by frameworks to make you think they do).

Essentially, a web applicaiton only exists when someone is actively connected to the site, and is posting or getting HTTP data. As soon as the request is done, the app is basically in limbo. After a certain period of inactivity, even the fake session times out and then there is nothing, until the next person connects.

So, the concept of “cross session” really is meaningless in a web application, because you will never know when someone else is connected or not, whether or not you can actually fire events to other sessions, etc… It will be a huge pain in the ass, error prone at best, and a disaster at worst.

Your best bet is simply create an “event” table in your database that each session can check everytime they do something. Then you can do whatever you want with those events. Just remember, the web is stateless.