Organizing MVC

> 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 bunch

You are welcome.

- Saish

Saisha at 2007-7-16 23:08:12 >