One of the things that bothers me about some cli/console packages is how the commands you write with them end up being tightly coupled to the “framework” the package provides. You extend a command controller, which itself may use service location, and it has to be dispatched to via a specific console mechanism. Your actual command (the business logic) ends up tightly coupled not just to a tool for a specific task but to the package as a whole.
Most of the time I don’t need a “full console application” — I just need to read some input for the command, run my actual command logic, and send some output from the command. The Leanpub Sampler from Matthias Noback is an example of the kind of thing I usually end up doing in small or one-off projects.
Look at the invocation file for the command to generate Leanpub and see how Matthias gets this command running: load the autoloader, create Aura.Cli context and stdio objects, define the getopt flags, and then (this is the key) pass the option values to his real command object.
The command is completely separated from the environment, and fully decoupled from the “framework” that launched the command. The command itself uses the Symfony Finder component and a series of custom iterators. The work performed by the command could run as part of a web process if we wanted. This is a very nice piece of work.
Now, if you want a full console application to combine together a bunch of stuff, that’s cool. Aura has Aura.Cli_Project for that, and there are other things out there for that as well. But the central point remains this: we should strive to keep the actual work of the command separated from the framework of the project as a whole.
One of the troubles we have with legacy code is that there’s very little separation of concerns. Setup work, business logic, and presentation logic are all intertwined and difficult to work with separately. As one result of that they are difficult to test.
But it doesn’t have to be that way. My newest book, Modernizing Legacy Applications in PHP, gives you step-by-step instructions on how to get your legacy code under control by eliminating globals and separating concerns. Each chapter shows you exactly one task and how to accomplish it, along with common questions related to that task. When you complete that chapter, you will have improved the quality of your application, and it will keep running until you decide to start the next chapter.