Console Application Structure

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 acce开发者_C百科ss 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?

---

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.