我正在开发一个相当大的应用程序，而我的技术主管和我在某些事情上的看法并不一致。
其中之一是关于控制台应用程序。这些应用程序正在从 shell 脚本移植到 C#。其中一些脚本相当大（转换后有 300-400 行代码），并且执行 I/O、电子邮件和数据库访问等操作。
我为每个脚本创建了一个类。每个类都有一个 Run 方法，它调用其中的任何方法/操作。在 Program.cs/main 中，我创建了该类的一个对象并调用 Run。 Program.cs包含4-5行代码。干净简单。
我的技术主管希望摆脱脚本类，而将所有内容都放在 program.cs 的 main 方法中。他的理由是，这样的做法太混乱了。
必须这样做感觉很尴尬，因为类不再可以重用/可打包到类库中，而不必摆弄 main 方法。
单元测试似乎不受影响，因为您可以实例化 Program.cs 本身，但同样......这感觉很笨拙。以他的方式做有什么我没有看到的好处吗？我的方法有什么好处吗？在您的主要方法中处理大型应用程序和内容时是否有通用做法？
感谢您的时间。
必须这样做感觉很尴尬，因为类不再可以重用/可打包到类库中，而不必摆弄 main 方法。
事实并非如此have就这样。
例如，每个脚本仍然可以具有相同的结构，但是also have a private static void Main(string[] args)方法。 （如果您愿意，它可以是非私有的 - 这完全取决于您的需求。）
这样它是独立的（可以编译为单个输入到单个输出然后运行），有时会很方便，但可能also用作类库的一部分。存在一个Main方法绝无可能prevents毕竟，该类正在从其他类中使用。
不清楚你是否有one Program.cs文件或每个脚本一个。如果每个脚本都有一个，每个脚本只有 4-5 行，那么看起来确实如此somewhat无意义。
现在这肯定不是我通常构建大型应用程序的方式 - 但如果重点是有几个“脚本”，每个脚本can独立运行，然后给每个类一个Main方法看起来还不错。
事实上，我经常做的事情是为了demo目的是有几个类Main单个项目中的方法，然后有一个单独的入口点（is in Program.cs）它使用反射来查找所有其他的，然后允许用户/演示者选择要运行的一个。
如果您的所有代码都可以放在一个类中，那么拥有一个微小的额外入口方法似乎并不是什么问题。如果它是actually单个类代码过多的情况不管至于入口点在哪里，那就是另一回事了。 （所以如果你坚持拥有一个ScriptClass当实际上你应该给不同的类分配不同的任务时，那也会很糟糕。）同样，如果他真的坚持所有代码都在一个单一的代码中method，这绝对是测试和可维护性的问题。
我建议你暂时把切入点的分歧放在一边：找出最简洁的方式来构建一切else关于代码，然后是否真的并不重要Main方法进入Program.cs或在另一个类中。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
