与使用类相反，有充分的理由在Program.cs/main中编写代码吗? [英] Is there a good reason to write code in Program.cs/main as opposed to using classes?

问题描述

我正在开发一个非常大的应用程序，并且我的技术负责人，在某些事情上我并没有看到意见.

I am working on a pretty large application and my tech lead and I are not seeing eye to eye on certain things.

其中之一与控制台应用程序有关.这些应用程序已从Shell脚本移植到C#.其中一些脚本相当大(转换后需要300-400行代码)，并且可以执行I/O，电子邮件和数据库访问等操作.

One of them is regarding console applications. These applications are being ported to C# from shell scripts. Some of these scripts are reasonably large (300-400 lines of code after conversion) and do things like I/O, Email and database access.

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

For each of these scripts I created a class. Each class has a Run method which calls any methods/operations that are within. Inside Program.cs/ main, I create an object of said class and call Run. Program.cs contains 4-5 lines of code. Clean and simple.

我的技术负责人希望摆脱脚本类，而只将所有内容包含在program.cs的主要方法中.他的理由是它太混乱了.

My tech lead wants to get rid of the script classes and just have everything inside the main method of program.cs. His reasoning is that it is too confusing the way it is.

这样做很尴尬，因为该类不再变得可重用/可打包到类库中，而不必摆弄main方法.

It feels awkward having to do it this way as the class no longer becomes reusable/package-able into a class library without having to fiddle with the main method.

单元测试似乎不受影响，因为您可以实例化Program.cs本身，但是同样....这感觉很笨拙.用我看不见的方式进行操作是否有任何好处?我有什么好处吗?在您的主要方法中处理大型应用程序和内容时，是否有一般惯例?

Unit tests seem like they are unaffected since you can instantiate Program.cs itself, but again....this feels clunky. Are there any benefits to doing it his way that I am not seeing? Are there any benefits my way? Is there a general practice when dealing with large applications and content in your main method?

谢谢您的时间.

推荐答案

这样做很尴尬，因为该类不再变得可重用/可打包到类库中，而不必摆弄main方法.

It feels awkward having to do it this way as the class no longer becomes reusable/package-able into a class library without having to fiddle with the main method.

那样没有.

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

For example, each of your scripts could still have the same structure it does, but also have a private static void Main(string[] args) method. (It could be non-private if you want - it all depends on your needs.)

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

That way it's standalone (can be compiled as a single input to a single output then run) which can occasionally be handy, but could also be used as part of a class library. The presence of a Main method in no way prevents the class being used from other classes, after all.

尚不清楚每个脚本中是一个 Program.cs文件还是一个.如果每个脚本只有一个脚本，而每个脚本只有4-5行，那么看起来有些毫无意义.

It's not clear whether you've got one Program.cs file or one per script. If you've got one per script, each of which is just 4-5 lines, that does seem somewhat pointless.

现在，这当然不是我通常构造大型应用程序的方式-但是，如果要点是要有几个脚本"，每个 都可以独立运行，然后给每个类Main方法似乎还不错.

Now this certainly wouldn't be how I'd normally structure a large application - but if the point is to have several "scripts" each of which can be run standalone, then giving each class a Main method doesn't seem too bad.

事实上，我经常为 demo 所做的工作是在单个项目中具有多个具有Main方法的类，然后具有单独的入口点(是在Program.cs中)，它使用反射来查找所有其他内容，然后允许用户/演示者选择要运行哪个.

In fact, what I often do for demo purposes is have several classes with Main methods in a single project, then have a separate entry point (which is in Program.cs) which uses reflection to find all the others and then allows the user/presenter to choose which one to run.

如果所有代码都包含在一个类中是有意义的，那么拥有一个很小的额外输入方法似乎不是问题.如果实际上实际上是单个类无论输入点在哪里的代码过多的情况，那就是另一回事了. (因此，如果您坚持只使用一个ScriptClass，而实际上您应该将不同的任务分配给不同的类，那也将是不好的.)同样，如果他确实坚持所有代码都在一个方法中，这绝对是测试和可维护性的问题.

If all your code makes sense to have in a single class, then having a tiny extra entry method doesn't seem such a problem. If it's actually a case of too much code for a single class regardless of where the entry point is, that's a different matter. (So if you stuck to having a single ScriptClass when actually you should give different tasks to different classes, that would be bad too.) Likewise if he really is insisting on all the code being in a single method, that's definitely a problem for testing and maintainability.

我建议您暂时将入口点问题放在一旁:找出最干净的方法来构造有关代码的所有其他内容，然后Main方法真的无关紧要进入Program.cs或另一个班级.

I suggest you set the entry point disagreement aside for the moment: work out the cleanest way to structure everything else about the code, and then it really doesn't matter whether the Main method goes in Program.cs or within another class.

这篇关于与使用类相反，有充分的理由在Program.cs/main中编写代码吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！