Why not using MVC pattern for CLI development

[tarikguney]

I think MVC is a great fit for CLI apps, and it is little frustrating to see how MS is missing it. Hence, I have developed my own command line development framework, CommandCore, which uses a simple MVC pattern. Perhaps, this library of mine can give some idea of what I am suggesting to see in this library, github.com/tarikguney/command-core . It is also available on Nuget: nuget.org/packages/commandcore.library.

[KathleenDollard]

Jon and I have talked a lot about MVC and where we parallel and don't really parallel.

Central to our design is the idea of what we call application models that wrap the System.CommandLine syntax.

I am working on a version at https://github.com/KathleenDollard/command-line-api-starfruit. It allows any class to be the definition of a command. Because I've had to invest time in recovering from an injury, it is going slowly. Feel free to give any feedback, or ask questions as I know there aren't docs.

We would welcome other application models if you want to borrow our engine. I didn't look deeply at what you were doing, but I found some interesting differences:

• The language itself. Actually using the phrase "View".
• The Options generic. (I just put those properties on the Command/Verb class or directly as parameters)
• Your use of "Render" language made me consider that any command class could have a few methods - run, help, etc
• Your "Associate multiple commands..." sample puts descriptions in place. I have to say that I have come to hate how that breaks up code and spreads out descriptions. If you agree, I'd love to find common patterns for people to use. I am currently using a dictionary with a "routing" string

If you want to explore using System.CommandLine as an engine for your surface area, let us know and feel free to let me know if you think any of the StarFruit work should be generalized to support other application models.