Joh*_*axx 28 c# program-entry-point
我正在研究一个非常大的应用程序和我的技术主管,我没有看到某些事情的一致看法.
其中一个是关于控制台应用程序.这些应用程序正从shell脚本移植到C#.其中一些脚本相当大(转换后有300-400行代码),并执行I/O,电子邮件和数据库访问等操作.
对于每个脚本,我创建了一个类.每个类都有一个Run方法,可以调用其中的任何方法/操作.在Program.cs/main中,我创建了一个所述类的对象并调用Run.Program.cs包含4-5行代码.干净简单.
我的技术主管希望摆脱脚本类,只需将所有内容都放在program.cs的main方法中.他的理由是它的方式太混乱了.
因为类不再可以重复使用/打包成类库而不必使用main方法,所以不得不这样做.
单元测试似乎没有受到影响,因为你可以自己实例化Program.cs,但是再次....这感觉很笨拙.按照我没有看到的方式做任何好处？我的方式有什么好处吗？在主方法中处理大型应用程序和内容时是否有一般做法？
感谢您的时间.
Jon*_*eet 35
因为类不再可以重复使用/打包成类库而不必使用main方法,所以不得不这样做.
它不具有被这种方式.
例如,您的每个脚本仍然可以具有相同的结构,但也有一个private static void Main(string[] args)方法.(如果你愿意,它可能是非私人的 - 这一切都取决于你的需求.)
这样它是独立的(可以编译为单个输出然后运行的单个输入),这有时可以很方便,但也可以用作类库的一部分.毕竟,Main方法的存在决不会阻止类从其他类中使用.
目前尚不清楚你是否有一个 Program.cs文件或每个脚本一个文件.如果你有一个脚本,每个脚本只有4-5行,这似乎有点无意义.
现在这肯定不是我通常构建一个大型应用程序的方式 - 但如果关键是要有几个"脚本",每个脚本可以独立运行,那么给每个类一个Main方法似乎并不太糟糕.
事实上,我经常做演示的目的是有几个班,Main在一个项目的方法,然后有一个单独的入口点(这是在Program.cs),它使用反射来发现所有的人,然后允许用户/主持人选择哪一个人跑.
如果你的所有代码都在单个类中是有意义的,那么使用一个微小的额外输入方法似乎不是一个问题.如果它实际上是单个类的代码太多的情况,无论入口点在哪里,那都是另一回事.(因此,如果您坚持使用单个ScriptClass实际应该为不同的类提供不同的任务,那也是不好的.)同样,如果他真的坚持所有代码都在一个方法中,那肯定是测试和可维护性.
我建议你暂时将入口点分歧放在一边:找出最简洁的方法来构建代码的其他所有内容,然后无论Main方法是进入Program.cs还是在另一个类中,这都无关紧要.