views:

83

answers:

1

Hi,
I am trying to understand and practice the MVC-pattern to improve my development. So I started refactoring an application I once wrote and have progressed so far. It is completely clear how my model looks like and also the view is ready so far. But now I am searching for a good practice to design my controller layer.
I have created a view that's split up in different main components. Let me give you a short example:

There are 3 Panels that group specific components:

  • "FilePanel", holding a JTextField and two JButtons
  • "DataPanel", holding all components neccessary to display some data and some JButtons
  • "CalendarPanel", showing some calendar-sheets

These three Panels are each in a separate class and afterwards instantiated and arranged in a GUI-class.

No the actual question. As I separate the Panels, how should I build the controllers? Should each panel get its own controller class (FileController, DataController, CalendarController)? Or should there just be one controller class for the whole view?

If I create one controller class for each panel, how do can I achieve that the controllers communicate with each other? Example: If a button is clicked in "FilePanel", how do I notify "DataPanel" about this?

Could you give me some examples of best practice?

+4  A: 

Are the Panels fundamentally separate?

NO: The set of panels is fundamentally one state. For example the panels represent a console showing different aspects of the same items under control. The user selects an item and all the other panels update to show views of the item. In this case one Controller is enough.

YES: That is can each of them move through various states independendently? This is the kind of realtionship you might have in a "Portal" style application. The user can work in each Panel pretty independently - extreme example, two separate side-by-side browser panes in one overall viewer. It's the kind of effect you get in Composite Applications where the user has windows open on different back-end systems. Sometimes user actions in one window cause things to happen in another window, but generally they run separately. In this case we have can have separate controllers each responsible for the state of a Panel. They can communicate with each other by event handling mechanisms. User clicks in File Panel, View contacts its controlled, which issues a "File Selected" event, whose payload is the id of the file. Note that the "click" event is translated into a non-ui specific event.

By having separate controllers we decouple the details of the current set of panels. Addind a new panel requires only that the new controller registers for events.

djna
Thank you, that makes my decision clearer. I guess in my case one Controller should be enough then.
Ham