控制台应用程序结构
在过去的 6 个月里，我编写了多个 .Net 控制台应用程序，并且我们在组织的不同项目中编写了更多的 .Net 控制台应用程序。我的控制台应用程序通常坚持相同的标准格式/结构。不幸的是，我们的许多控制台应用程序都没有。
我一直在研究标准化这些控制台应用程序结构的方法。我还想为控制台应用程序的基本结构提供一个框架，并提供对处理参数传递、日志记录等事务的标准方法的轻松访问。
任何人都可以建议解决这些问题的最佳实践吗？我一直在阅读这篇关于 .Net 中的控制台应用程序的 MSDN 文章这建议了控制台应用程序的设计模式。该示例使用模板方法模式来处理我之前列出的一些问题。
文章中列出了使用这种方法的两个缺点。
- 最终的类数量是原来的两倍
- 有许多简单、相似的类
任何人都可以建议更好或更标准的方法来处理这个问题吗？用这种方法列出额外的负面影响怎么样？
I've written several .Net Console Applications over the past 6 months and we have many more throughout different projects in our organization. I generally stick to the same standard format/structure for my Console Applications. Unfortunately, many of our console applications do not.
I have been looking into ways of standardizing the structure of these Console Applications. I would also like to provide a framework for the basic structure of a Console Application and provide easy access to standard ways of handling things such as argument passing, logging, etc.
Can anyone suggest Best Practices for addressing these concerns? I have been reading this MSDN article on Console Applications in .Net which suggests a Design Pattern for Console Apps. The example uses a Template Method pattern to handle some of the concerns I listed earlier.
Two negatives of using this approach are listed in the article.
- Ending up with twice as many classes
- Having many simple, similar classes
Can anyone suggest better, or more standard, ways of handling this? What about listing additional negatives with this approach?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
为了回答我自己的问题的一部分......
我确实花了相当多的时间寻找一种标准方法来处理传递给我的控制台应用程序的参数的解析。我专门寻找类似于 Python 的 GetOpt 的东西。考虑到这一点，我选择的解决方案是 NDesk.Options。它涵盖了我们所有的需求，并且似乎以标准方式处理争论。我认为这可能会对在搜索中偶然发现这个问题的人有所帮助。
To answer part of my own question...
I did spend quite a bit of time looking for a standard way to handle the parsing of arguments passed to my console applications. I was specifically looking for something similar to GetOpt for python. With that in mind, the solution that I settled on is NDesk.Options. It covers all of our needs and seems to handle arguments in a standard fashion. I thought this might help someone who stumbles on this question in their search.
我倾向于使控制台应用程序尽可能简单，并尽可能多地放在另一层中，以便更容易进行单元测试和验收测试。我通常还保持控制台应用程序简单/单一任务，因此我通常不会有很多可能的路径通过命令行参数之类的东西。这允许我只获取参数（如果有），解析它们并将它们传递给“后端”逻辑。
I tend to keep my console applications as simple as possible and as much in another layer so that it can be more easily unit and acceptance tested. I also generally keep my console applications simple/single tasked, so I don't often have many possible paths through things like command line arguments. This allows me to just take the arguments, if any, parse them and pass them along to "back end" logic.