My question concerns an administrator's console application. The requirements around it are that administrators should be able to log in (other types of user cannot), and they should then be able to do things like look at requests from users, assign requests to themselves, ban users (temporarily or permanently), and grant/revoke permissions for other users. All activity should be logged.
Its a console style application. Not like UNIX but rather with an option style interface. I.e. 1) Ban User, 2) View requests.... and so on, and the user then selected a number and is then prompted for whatever info is needed.
I'm trying to draw a class diagram for this. I've attempted this a few times in the past, but I want to do it well, so its extensible and to follow an MVC pattern. E.g. if I decided to add a GUI view later, I'd like to easily be able to make that addition.
So this is what I'm thinking. I'd appreciate feedback on my line of thinking and what I could do differently...
- InitController's handle() method runs first. InitController has a View object (an interface, currently only realised by the class ConsoleView).
- InitController sends to ConsoleView a string (please enter a username) and gets back whatever the user types in. Then does the same for password.
- InitController has an object which goes and checks the credentials are correct in the database, and returns true/false.
Assuming the credentials are correct, InitController then calls the handle() method inside MainMenuController.
MainMenuController sends the options to the View to be printed out, and the view returns the selected option. (options here might be 1: Ban, 2: Requests, 3: Privileges or something similar).
- If option 1 was pressed, handle() gets called in the BanController. If option 2 gets pressed, handle() gets called in the RequestsController. And so on.
This requires MainMenuController to have a BanController, RequestsController and a PermissionsController which sounds bad to me, or can this just not be avoided? Is it okay for Controllers to know about each other in MVC or are they meant to be kept separate?
All the controllers would have a Logger object too, so they can call Logger.log() to log all activity.
Should the View be doing more? It currently just takes options and then figures out how to display them to the user. In this case, by printing them out. And then sends back the user's response.
Appreciate any guidance with this. Thanks.
EDIT: When the Controller passes the options to the view, it could do this by sending Option objects. These Options can have an int (what option they are), String (description of the option to print out), and a Controller - so if that option gets selected, the View can call option.getController().handle(). Would something like this be better? That would stop the controllers knowing about each other right? But then the view knows about the controller.
EDIT 2: Another line of thinking I've thought of is: Instead of controller being the first thing to run, its a class called the InitialConsoleView and where I just print out the prompts for username and password. They're then passed to LoginController, which returns true/false depending on whether the credentials are valid. If they are, InitialConsoleView then calls a method in MainMenuView.
I'd end up with a lot more View objects, and this time the Views would know about each other instead of the Controllers knowing about each other as they would previously. This again sounds like a bad thing to me.
I've read a lot of material about MVC but really stumped with how to do this.