Organizing MVC

Question

Hi, I'm just learning MVC and I have few questions.
As the class count increases with MVC, how do you usually organize the models, views and controllers in Java packages? I think I'm trying to "tie them together" too much. Also, should I think like that the Models arent actually a part of the MVC at all?
I have Screens (views) like TitleScreen, OptionsScreen, HelpScreen. They all have an abstract base class Screen that has a Window (which contains all smaller components like buttons etc.). Now I'm gonna have quite many of these screens and I'm wondering if it's practical for each of them to have a separate controller, model and view. Some of them are pretty simple and may have just like few buttons which have some simple actions. Also, if I know that, for example, some controller isn't gonna change, could I make things easier by declaring it as inner class or something. I'm not really trying to achieve any kind of superior flexibility but mainly just a practical division between the view and data.
Especially the controller part is hardest to think of maybe because of the simplicity of my screens. And I'm not too sure of all it's responsibilities.
Let's say I want to have a screen that shows a list of Players, and it's possible to create, delete and choose players in it. So as I've understood I should create:
- TitleScreen (has a Window, which in turn has the List that displays the Players)
- TitleState (contains the actual player-objects, and some methods to interact with them)
- TitleController (first things that come into my mind are methods like createPlayer(String), deletePlayer(String), but I think they would fit to TitleState too?)
How would you design the above classes?
Another thing I'm confused of is that in some examples I've seen the View has a reference to the model and sometimes it seems to pull data directly from it (using getters) and sometimes it gains them as events. Which one should I prefer?
Also, how do you usually name the models, views and controllers?
Thanks a bunch

Answer 1

Hi, I'm just learning MVC and I have few questions.
As the class count increases with MVC, how do you
usually organize the models, views and controllers in
Java packages? I think I'm trying to "tie them
together" too much. Also, should I think like that
the Models arent actually a part of the MVC at all?
There are two high-level package organization options, neither of which is either correct or incorrect, but rather a matter of preference. After your domain, you can either go tier and then component or vice versa. Here are two examples:
com.foo.controller.account
com.foo.controller.invoice
com.foo.model.account
com.foo.model.invoice
com.foo.view.account
com.foo.view.invoice
or
com.foo.account.controller
com.foo.account.model
com.foo.account.view
com.foo.invoice.controller
com.foo.invoice.model
com.foo.invoice.view
I have Screens (views) like TitleScreen,
OptionsScreen, HelpScreen. They all have an abstract
base class Screen that has a Window (which contains
all smaller components like buttons etc.). Now I'm
gonna have quite many of these screens and I'm
wondering if it's practical for each of them to have
a separate controller, model and view. Some of them
are pretty simple and may have just like few buttons
which have some simple actions. Also, if I know that,
for example, some controller isn't gonna change,
could I make things easier by declaring it as inner
class or something. I'm not really trying to achieve
any kind of superior flexibility but mainly just a
practical division between the view and data.
There is no reason that a series of common screens, presumably with common functionality offered, could not also have controllers that have common functionality. Either refactor the common controller code to a helper object or an abstract controller super-class.
What you have stumbled upon is that it is very difficult to separate the view from the controller. The controller's responsibilities are to response to user requests and dispatch model data to the appropriate view. As such, the controller is 'dependent' on both the model and the view. Neither model nor view, however, should be dependent on the controller.
Within a standard GUI application, any events that you process are candidates for controller code. These include button clicks, menu clicks, etc. Now, you can simply leave these as event listeners or you can refactor them into proper controllers. This would mean that you instantiate a given controller which would be responsible for managing a given view. The methods on the controller would alter the state of the view.
Especially the controller part is hardest to think of
maybe because of the simplicity of my screens. And
I'm not too sure of all it's responsibilities.
See above. Also note that it is hard to decouple the view and controller. For most GUI applications, you really do not need model-view-controller, you simply need model-delegate, where delegate is a mish-mosh of view and controller responsibilities.
Let's say I want to have a screen that shows a list
of Players, and it's possible to create, delete and
choose players in it. So as I've understood I should
create:
- TitleScreen (has a Window, which in turn has the
List that displays the Players)
- TitleState (contains the actual player-objects, and
some methods to interact with them)
- TitleController (first things that come into my
mind are methods like createPlayer(String),
deletePlayer(String), but I think they would fit to
TitleState too?)
That is fine. Your controller is delegating a request to the model class. That is normal. It might seem odd the signatures are similar (or wasteful), but to do proper MVC, the view should invoke a controller which will invoke the model which and then finally pass the model result(s) if any to either the same or a different view.
How would you design the above classes?
See above.
Another thing I'm confused of is that in some
examples I've seen the View has a reference to the
model and sometimes it seems to pull data directly
from it (using getters) and sometimes it gains them
as events. Which one should I prefer?
It depends on how much decoupling you want. You can have your controllers or your views act as listeners or observers (via the observer-observable pattern). However, the model generally should stand on its own.
Also, how do you usually name the models, views and
controllers?
Personal preference. Remember from above that the package structure itself will give you a clue as to what tier you are in.
Thanks a bunchYou are welcome.
- Saish