问在Program.cs/main中编写代码，而不是使用类，有什么好的理由吗？

EN

这样做感觉很尴尬，因为类不再是可重用/可打包到类库中的，而不必摆弄main方法。

它不一定是那样的。

例如，您的每个脚本可以仍然具有相同的结构，但也可以具有private static void Main(string[] args)方法。(如果你愿意，它可以是非私有的--这完全取决于你的需求。)

这样，它就是独立的(可以编译为单个输入到单个输出，然后运行)，这有时会很方便，但也可以用作类库的一部分。毕竟，Main方法的存在并不能阻止其他类使用该类。

还不清楚你是有一个Program.cs文件，还是每个脚本有一个。如果每个脚本都有一个脚本，每个脚本只有4-5行，那么这看起来就有点无意义了。

现在，这肯定不是我通常构建大型应用程序的方式-但是如果重点是要有几个“脚本”，每个脚本都可以独立运行，那么为每个类提供一个Main方法看起来并不是太糟糕。

事实上，出于演示的目的，我经常做的是在一个项目中有几个带有Main方法的类，然后有一个单独的入口点(在Program.cs中)，它使用反射来查找所有其他的类，然后允许用户/演示者选择运行哪一个。

如果您的所有代码都放在一个类中是有意义的，那么拥有一个微小的额外入口方法似乎不是什么问题。如果实际上是单个类的代码太多，而不管入口点在哪里，那就是另一回事了。(因此，如果您坚持只有一个ScriptClass，而实际上您应该将不同的任务分配给不同的类，这也是不好的。)同样，如果他真的坚持将所有代码放在一个方法中，这肯定会给测试和可维护性带来问题。

我建议您暂时把入口点分歧放在一边:找出一种最简洁的方式来组织代码的其他所有内容，然后Main方法是放在Program.cs中还是放在另一个类中都无关紧要。

老实说，我认为你是在为自己创造工作。我不能从你描述的细节中判断--但如果shell脚本一直在工作，为什么要在显然不需要结构的地方构建它呢？

你说模块化和重新打包到外部库中是你需要做的事情--我会反驳“为什么？”(这就是我所说的额外工作)。

如果你在一个文件中创建了一组简单的方法--那就是一个文件！根据定义，它将比多个项目更容易处理。

也就是说，除非有更多的细节，否则很难知道我们在谈论什么。如果是“发送一份夜间报告并给这些人发邮件”--是的，这是不需要类库和大量模块化的东西。运行一个方法，你就完成了。

您知道控制台应用程序的入口点是可配置的，对吧？

我更喜欢的方法是：

class MeaningfullyNamedProgram { 
    public static void Main(string[] args) {
        var program = new MeaningfullyNamedProgram(args);
        program.Run();
    }

    public MeaningfullyNamedProgram(string[] args) { 
    }

    public Run() {
        // well structured, broken-out code follows 
    }
}

将项目的入口点指向MeaningfullyNamedProgram.Main

注意:我将把它留给读者作为练习，但是您可以使用泛型为它创建一个基类，这样就省去了一些输入。