I just learned about the MVC architecture. I was going back and working on a command line file transfer application I wrote, and I was curious, to what degree should command line interfaces follow the MVC pattern?
Mvc – Command Line Interface MVC Architecture
command linemvc
Related Solutions
Use what you want. Use what makes sense for what you are doing now.
While I'm mostly a command line guy (I use the GUI only to get a graphical representation of revision graph), I've trouble to understand why you think using the command line gives you a better understanding of what happens behind the hood (well excepted for GIT :)), usually there is a clear mapping between the two even if CL may give you access to some little used features.
Now in my opinion, automating what can be automated in the process is part of the job and for that, CL is mandatory.
I'm going to answer my own question after a day of research. In the end this ended up looking more towards cron jobs which support MVC web applications (which isn't exactly the same as my original question but yielded some interesting information none-the-less). Anyway, here's what I found:
Q. The concept of routing all requests to one file is a little bit redundant because there can only be one entry point?
A. Correct, it is redundant because command line applications can only have one entry point, the executable file itself. You do not need to use the Front Controller pattern in your executable file unless you have sub commands. A lot of simple command line applications are essentially modelled in the same way as a large Bash script. You may want to use the Front Controller pattern if your command line application has sub commands.
Q. It also feels to me as though the concept of routing using controllers and actions is a little bit odd as well. When I have stuck to the MVC pattern with command line applications I almost always end up with one controller with only one or two actions. This seems like a signal that I am not using the front controller (or possibly even the MVC pattern) correctly?
A. That is also correct. If you are building command line applications to support MVC web applications it does not make sense to put your command line application logic inside a controller. In terms of a web application, controllers are for web requests, not command line applications. It should instead go in its own class. Sometimes these classes are referred to as "Tasks" or "Commands" or "Console Commands" within web framework communities.
Try leaving your controllers just for web requests and adding those sort of things to a Commands namespace or similar. There is one caveat here though, it is perfectly fine to use the M from MVC (Models) in your commands however. From my research it appears uncommon to utilise the V (views) in console commands either, just handle the output with simple echos and such.
Within your Command class it appears that it is very common to have only one method called run or execute. This contains the logic of your command and this leads onto your next question.
Q. Is there a better way to handle routing and dispatching requests within a command line application?
A. Yes, leave the MVC pattern alone for a web frameworks as it works well. For running cron jobs add another C to your acronym, that C should represent the word Console. In this new MVCC (that it used in jest, I'm sure that is already a proper acronym for another pattern) web requests come in through a front controller and so on as usual. For cron jobs create a second entry point (outside of the webroot directory) which triggers a specific Console class's run method to be executed.
I hope this will help someone, I've included some suggested reading material below:
http://maxoffsky.com/code-blog/practical-laravel-using-cron-jobs-in-laravel/ http://symfony.com/doc/current/components/console/index.html http://book.cakephp.org/2.0/en/console-and-shells.html https://www.gnu.org/prep/standards/html_node/Command_002dLine-Interfaces.html
Best Answer
Model View Controller isn't just for applications with GUI's. Very simply it's the idea that you can separate your code into at least three areas of responsibility. Actually, under MVC the fact that your application is a CLI is a detail to which the model can be blissfully unaware. One of the advantages of this is that means you can use the same model untouched if you decide to make a GUI version of your App.
CLI or not, the "degree" to which you should follow MVC depends entirely on how much you care about writing code that welcomes a requirements change. Otherwise, feh, who cares?