我正在构建一个宠物软件，其描述是:“网络上的外壳”。我将制作一个 shell 来与 API 进行通信，主要是为了敏捷化您在网络上经常执行的所有任务。
我需要有关如何在 .NET 4 (C#) 中设计该软件的帮助。
我一开始，软件被分成 3 个 DLL:UI -> 连接器 -> 命令[]。 (不是3个DLL，因为每个命令都在单独的DLL中)
UI 使用连接器项目执行另一个.dll 中的命令，该项目具有命令项目实现的接口(interface)。使用反射(在UI中)我执行该接口(interface)的实现，因此所有命令都是独立的并且与主项目分开。
在该连接器项目中，有一个名为Shell的类型，它是将输出发送到UI的促进器。因此，当有人构建命令时，他将发送文本或其他内容，例如使用.Net框架的System.Console。
我真的很想保持这个 SHELL 类静态，但是该类有状态，每个请求必须有一个独立的状态。因此，据我所知，静态类将具有应用程序池的生命周期。我说得对吗？
最佳答案
如果您认识到 Shell 必须具有状态，那么它不应该是静态的。无论是控制台应用程序还是 Web 应用程序。一件事是，您可以在单线程应用程序中安全地使用它，您知道没有其他人使用您的类，但另一件事是，这是一个很好的设计。
如果您的类具有某种需要为许多函数和所有实例共享的配置，则可以为该数据声明静态属性或字段。但不同线程需要不同的数据必须是非静态的。
此外，在多线程环境中，例如网络应用程序，您必须设计您的类，使其线程安全，否则您会遇到麻烦。如果您有一个具有静态方法但没有静态数据的类，那么您不必担心线程安全性。
只要 Web 应用程序中静态类的“预期生命周期”足够长，它就能承受多次请求，但请记住，Web 服务器的主线程会不时自动重新启动(取决于 IIS 配置) )，这样您就不能信任静态成员“永远”保存数据。您应该在应用程序启动事件上设置静态数据，并将更改的数据存储在永久存储(通常是数据库)中，以确保应用程序重新启动后可以恢复。
所以你最好改变你的类设计。这不应该假设在您的控制台应用程序中进行许多更改(除了使用更多新的)。
关于.net - Web 上下文中静态类的生命周期，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/9813095/