ASP.net MVC: Où conserver les données d'application?

Question

Je commence tout juste à porter une application sur ASP.net MVC et j'ai un objet contenant l'état de l'application (il garde une trace de certains processus en cours d'exécution sur la machine, démarrant et s'arrêtant si nécessaire et envoyant / recevant un message MSMQ).

Où devrais-je conserver cet objet? Dans mon application actuelle (basée sur HttpListener), il s'agit d'un singleton, mais je sais que les singletons rendent les tests difficiles. Il serait difficile de simuler ou de tester cet objet, du moins dans le contexte de l'application MVC elle-même, et il dispose de son propre ensemble de tests en dehors de l'application. Cependant, il peut être nécessaire de le remplacer par un stub pour le test.

L'objet doit être mis à la disposition d'un certain nombre de contrôleurs. Où devrais-je stocker cet objet et comment dois-je le mettre à la disposition des contrôleurs? Je n'ai jamais vu un cas comme celui-ci décrit dans les exemples ASP.net MVC que j'ai vus.

MISE À JOUR:

Je suppose que je dois expliquer pourquoi je ne peux pas stocker ces données dans une base de données. Je dois d’abord expliquer ce que fait l’application:

L'application sert des images générées dynamiquement par un certain nombre de "moteurs", qui sont des processus en cours d'exécution sur le serveur, communiqués via MSMQ. Permet d'appeler l'objet que je pose à la question à propos de EngineManager. Le processus ressemble à ceci:

1. Le client envoie une requête XML au serveur, en lui donnant le nom de "moteur". à utiliser, ainsi qu'un certain nombre de paramètres décrivant l'image.
2. L'application vérifie le EngineManager pour voir si ce moteur est en cours d'exécution. Sinon, ça commence.
3. L'application envoie un message MSMQ au moteur et attend la réponse.
4. L'application renvoie l'image générée au client.
5. Si, à un moment quelconque, le moteur s'arrête ou tombe en panne, l'application doit en être consciente pour pouvoir être redémarrée à la prochaine requête adressée à ce moteur.
6. À la fermeture de l'application, tous les moteurs sont également arrêtés.

Plusieurs contrôleurs traitent ces demandes, chacun effectuant un travail légèrement différent. Tous doivent communiquer avec le même EngineManager, comme il doit également, dans certaines situations, synchroniser l'accès à d'autres ressources.

Comme vous pouvez le constater, ce n'est pas votre serveur Web classique sauvegardé sur une base de données.

Answer 1

Si vous souhaitez que cet objet soit disponible pour tous les utilisateurs, c'est-à-dire qu'il n'est pas spécifique à une session, vous pouvez envisager de le stocker dans l'état de l'application:

http://msdn.microsoft.com/ en-us / library / bf9xhdz4 (VS.71) .aspx

Cependant, l’état de l’application présente plusieurs inconvénients, tels qu’énumérés sur la page liée ci-dessus. Par conséquent, assurez-vous que ces problèmes ne vous concernent pas avant de suivre cette voie. En général, je quitte l’état Applciation et stocke les données d’application dans une base de données principale. Si vous ne souhaitez pas suivre cette route, l'état de l'application peut vous convenir.

Answer 2

Vous devez transmettre l'objet au constructeur de chaque instance Controller , et les méthodes d'action du contrôleur doivent toutes utiliser l'instance d'objet transmise au constructeur de l'instance Controller .

Le ControllerFactory par défaut fourni avec ASP.NET MVC ne vous permettra pas de le faire. Cependant, il existe des frameworks d’addon gratuits (celui que j’aime bien, Autofac) qui permettent ce style de programmation.

Answer 3

Conservez les données de votre application dans la base de données et accédez-y par couche de modèle. Le client conserve uniquement son identifiant de session.