我在过去的6个月里写了几个.Net控制台应用程序，我们组织的不同项目中还有很多。我通常坚持使用与我的控制台应用程序相同的标准格式/结构。不幸的是，我们的许多控制台应用程序都没有。
我一直在研究如何标准化这些控制台应用程序的结构。我还想为控制台应用程序的基本结构提供一个框架，并提供对标准方法的轻松访问，例如参数传递，日志记录等。
有人可以建议解决这些问题的最佳做法吗？我一直在Console Applications in .Net上阅读这篇关于控制台应用程序设计模式的MSDN文章。该示例使用模板方法模式来处理我之前列出的一些问题。
本文列出了使用此方法的两个否定因素。
任何人都可以提出更好或更标准的处理方法吗？那么用这种方法列出其他负面因素呢？
答案 0 :(得分：2)
回答我自己的一部分问题......
我花了很多时间寻找一种标准方法来处理传递给我的控制台应用程序的参数的解析。我特意寻找类似于GetOpt for python的东西。考虑到这一点，我确定的解决方案是NDesk.Options。它涵盖了我们所有的需求，似乎以标准方式处理论点。我认为这可能会帮助那些在搜索中偶然发现这个问题的人。
答案 1 :(得分：0)
我倾向于保持我的控制台应用程序尽可能简单，并且在另一层中保持这样，以便它可以更容易地进行单元和验收测试。我通常也会将我的控制台应用程序保持简单/单一任务，所以我通常不会有很多可能的路径，比如命令行参数。这允许我只是接受参数，如果有的话，解析它们并将它们传递给“后端”逻辑。