C# 是否有充分的理由在Program.cs/main中编写代码而不是使用类？

我正在开发一个相当大的应用程序，我的技术主管和我在某些事情上的看法并不一致

其中之一是关于控制台应用程序。这些应用程序正在从shell脚本移植到C#。其中一些脚本相当大（转换后有300-400行代码），可以执行I/O、电子邮件和数据库访问等操作

对于每一个脚本，我都创建了一个类。每个类都有一个Run方法，该方法调用其中的任何方法/操作。在Program.cs/main中，我创建了上述类的一个对象并调用Run。Program.cs包含4-5行代码。干净简单

我的技术负责人想摆脱脚本类，把一切都放在program.cs的主方法中。他的理由是，这太令人困惑了

这样做会让人感觉很尴尬，因为类不再能够在不必修改main方法的情况下重用/打包到类库中

单元测试似乎不受影响，因为您可以实例化Program.cs本身，但再次……这感觉很笨拙。以他自己的方式做这件事有什么我看不到的好处吗？我这样做有什么好处吗？在主方法中处理大型应用程序和内容时，是否有一般做法

---

感谢您抽出时间。

您的技术主管需要好好谈谈！把所有东西都放进Program.cs不是前进的方向

这样做会让人感觉很尴尬，因为类不再能够在不必修改main方法的情况下重用/打包到类库中

不一定要这样

例如，您的每个脚本可能仍然具有与它相同的结构，但也有一个

private static void Main（string[]args）

方法。（如果你愿意，它可以是非私人的——这完全取决于你的需要。）

这样一来，它是独立的（可以编译为单个输入到单个输出，然后运行），偶尔会很方便，但也可以用作类库的一部分。毕竟，

Main

方法的存在并不能阻止该类从其他类中使用

现在还不清楚您是有一个

Program.cs

文件还是每个脚本有一个。如果每个脚本都有一个脚本，每个脚本只有4-5行，那么这看起来确实有些毫无意义

这当然不是我通常构建大型应用程序的方式——但如果关键是要有几个“脚本”，每个脚本都可以独立运行，那么给每个类一个

Main

方法似乎并不太糟糕

事实上，出于演示目的，我经常在一个项目中使用几个带有

Main

方法的类，然后有一个单独的入口点（位于

Program.cs

），该入口点使用反射查找所有其他类，然后允许用户/演示者选择运行哪个类

如果将所有代码都放在一个类中是有意义的，那么拥有一个小小的额外入口方法似乎不是什么问题。如果不管入口点在哪里，一个类的代码太多，这是另一回事。（因此，如果你坚持使用一个

ScriptClass

，而实际上你应该给不同的类分配不同的任务，那也太糟糕了。）同样，如果他真的坚持所有的代码都在一个方法中，那肯定是测试和可维护性的问题

---

我建议您暂时把入口点的分歧放在一边：找出最干净的方法来构造代码的所有其他内容，然后不管

Main

方法是进入

Program.cs

还是进入另一个类。

将逻辑拆分为一个或多个单独的类这是一条路要走。把所有这些都放在一个地方违反了坚实和干燥的设计原则。你的方法肯定是对的

---

你越是把你的类集中在单个角色上，你的维护和测试就越容易。

好吧，他的方法在概念上更简单，因为它是在子程序发明之前编写程序的方式

您的方式更好：它支持可重用性，并且更易于修改和调试

---

我能想到的唯一其他理由是，如果你按照自己的方式做比按照他的方式做要花更长的时间。但这是他短期思考的一个例子。你的方式将更好地经受时间的考验

你的技术线索错了。您提出的方法更加合理——它允许轻松地合并不同的脚本。每个脚本都有自己的

Main

方法，这可能会变得笨拙，尤其是当您计划使用一个可以同时运行其中几个方法的应用程序时。

如果该功能可以通过控制台程序以外的其他方式使用，当然您应该将它们保存在一个精确建模的类库中。通过将命令行参数处理与封装的功能纠缠在一起来节省几行代码是没有意义的，因为这些关注点最初是分开的。也许你的技术主管应该为你找到更有成效的工作。老实说，我认为你是在为自己创造工作。我不能从你描述中的细节中判断出来——但是如果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 
    }
}