是否有充分的理由在Program.cs / main中编写代码而不是使用类？
我正在研究一个非常大的应用程序和我的技术主管，我没有看到某些事情的一致看法。
其中一个是关于控制台应用程序。 这些应用程序从shell脚本移植到C＃。 其中一些脚本相当大（转换后有300-400行代码），并执行I / O，电子邮件和数据库访问等操作。
对于每个脚本，我创建了一个类。 每个类都有一个Run方法，可以调用其中的任何方法/操作。 在Program.cs / main中，我创建了一个所述类的对象并调用Run。 Program.cs包含4-5行代码。 干净简单。
我的技术主管希望摆脱脚本类，并将所有内容都放在program.cs的main方法中。 他的理由是它的方式太混乱了。
这种方式感觉很尴尬，因为类不再可以重复使用/打包成类库而不必使用main方法。
unit testing看起来好像没有受到影响，因为你可以自己实例化Program.cs，但是再次….这感觉很笨拙。 按照我没有看到的方式做任何好处？ 我的方式有什么好处吗？ 在主方法中处理大型应用程序和内容时是否有一般做法？
感谢您的时间。
这种方式感觉很尴尬，因为类不再可以重复使用/打包成类库而不必使用main方法。
它不一定是这样。
例如，您的每个脚本仍然可以具有相同的结构，但也具有private static void Main(string[] args)方法。 （如果你愿意，它可能是非私人的 – 这一切都取决于你的需求。）
这样它是独立的（可以编译为单个输出然后运行的单个输入），这有时可以很方便，但也可以用作类库的一部分。 毕竟， Main方法的存在绝不会阻止类从其他类中使用。
目前尚不清楚你是否有一个 Program.cs文件或每个脚本一个。 如果你有一个脚本，每个脚本只有4-5行，这似乎有点无意义。
现在这肯定不是我通常构建一个大型应用程序的方式 – 但如果关键是要有几个“脚本”，每个都可以独立运行，那么给每个类一个Main方法似乎并不太糟糕。
事实上，我经常为演示目的做的是在一个项目中有几个带有Main方法的类，然后有一个单独的入口点（在Program.cs ），它使用reflection来查找所有其他的，然后允许用户/演示者选择运行哪一个。
如果你的所有代码都在单个类中有意义，那么使用一个微小的额外输入方法似乎不是一个问题。 如果它实际上是单个类的代码太多的情况， 无论入口点在哪里，那都是另一回事。 （因此，如果您坚持使用单个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
注意：我会把它留给读者练习，但你可以使用generics为它创建一个基类，并节省一些打字。
您的技术主管需要很好的交谈！ 将所有内容放入Program.cs并不是前进的方向。
好吧，他的方式在概念上更简单，因为它是在子程序发明之前编写程序的方式….
你的方式更好：它支持可重用性，更容易修改和调试。
我能想到的唯一另一个理由是，如果你按照自己的方式花费的时间比按照自己的方式做的要长得多。 但这是他的短期思考案例。 你的方式将经得起时间的考验。
你的技术领先是错误的。 您提出的方法更合理 – 它允许轻松合并不同的脚本。 每个具有自己的Main方法的脚本都会变得笨重，特别是如果您计划拥有一个可以同时运行其中几个的应用程序。
将逻辑拆分为单独的类（或类）是可行的方法。 将它们全部放在一个位置违反了SOLID和DRY设计的原则。 你的方法肯定在正确的轨道上。
您将课程专注于单一角色的次数越多，您的维护和测试生活就越容易。
如果function可以通过除控制台程序之外的其他方式使用，当然您应该将它们保存在nicelly建模的类库中。 通过将命令行参数处理与封装function相结合来保存几行代码是没有意义的，因为问题最初是分开的。 也许你的技术主管应该为你找到更有成效的任务恕我直言。