I'm building a pet software that the description is: "a shell on the web". I'll do a shell to comunicate with API mainly to agilize all tasks you do frequently on the web.
I need help to how design this software in .NET 4 (C#).
I'm in the beginning and the Software was separated in 3 DLL: a UI -> Connector -> Commands[]. (Is not 3 DLL because each command is in a separate DLL)
UI execute a command that was in another .dll using Connector Project which has an interface that a Command Project implement. Using reflection (in UI) I execute the implementation of that Interface, so all commands are independent and separate from the main project.
In that Connector project a have a type named Shell which is a facilitator to send the output to the UI. So when someone is building a Command he will send texts or other stuff like using System.Console of the .Net framework.
I really want to keep this SHELL class static, but that class have state and each Request must have a independent state. So, by my knowledge a static class will have a lifetime for Application Pool. I'm correct?
If you recognize that Shell must have state, then it shouldn't be static. No matter if it's a console app or a web application. One thing is that you can use it safely in a single thread app where you know no-one else uses your class, but a very different thing is that that's a good design.
If your class has some kind of configuration that needs to be shared for many functions and all the instances, it's ok to declare static properties or fields for that data. But the data which need to be different for different threads, must be non-static.
Besides, in a multi-thread environment, like a web app, you must design your class so that it's thread safe, or you'll run into troubles. If you have a class that hast static methods, but not static data, then you don't have to worry about thread-safety.
As long as the "life expectancy" of your static class in a web app, it will survive a number of requests, but remember that the main thread of the web server will restart automatically from time to time (depending on IIS configuration) so that you can't trust on static members to keep data "for ever". You should set-up your static data on Application Start event, and should store changed data in a permamnet store (generally a database) to assure it can be recovered after an application restart.
So you're better off changing your class design. That shouldn't suppose doing many changes in your console app (apart from using a few more new's).
