Post by JS » Mon, 10 Jan 2005 06:54:36

In this kind of architeture is it always the Controller part that contains
the main method?


Post by Gerbrand v » Mon, 10 Jan 2005 07:51:35

JS schreef:

I might do it all wrong, but my main class is the main (J)Frame.

In the constructor I instantiate the the controller class. Using events,
data is retrieved from the 'model' (database) via the controller.



Post by Thomas G. » Tue, 11 Jan 2005 00:48:04

Gerbrand van Dieijen coughed up:

*To the side* of where the controller is fired up, using the main JFrame as
the holder of main() is not a /particularly/ clean idea.

1. You want to keep the holder of the "main" main() :) outside of any of
the display objects.

For a quick example, what if you wanted to add an additional JFrame to the
app? You would then have the ugly code of having the main() within one
JFrame instantiate another JFrame.

If you wanted to add an AWT startup initialization window to your swing app,
that too would live in the "wrong" place.

2. Renaming the main JFrame also changes your entry point to the
application. Or you might wish to later on make the main JFrame a mere
JComponent of a yet bigger JFrame.

3. It is a good idea to have main() methods sprinkled throughout your code
to act as test harnesses for the individual components. For example, your
main JFrame() might have a main() method, but not as the entry point to the
application, it is merely a quick entry point to unit test the JFrame by
itself. This incredibly useful, mostly because it documents to you later on
just what you used to unit test the component before adding it to the
application. If there is a bug later on, you can inspect what each
component was tested with /when/ you were designing it. A WizbangButton,
for example, might have its own main() for testing it against different
layout managers, etc.

With knowledge comes sorrow.


Post by Gerbrand v » Tue, 11 Jan 2005 06:36:59

Thomas G. Marshall schreef:

Well of course I've programmed more applications, but in this case the
application main JFrame only has an pull down menu.
Events in the pull down will cause new windows to pop up, including new
All, or at least most of those new Windows can run on their own too.

I've put that in the constructor. I could use another class for that (in
fact I had such a class for some other applications), but it's very
small. It would only construct my main controller class and initialize
the window.

In this case I would have to change one setting (in the exe4j config
file). If I'd use another class, I would have change something anyway,
in that particular class.

I agree on that. It also encourages the OO philosophy of separation and
isolation (well maybe another term, but it's something good).


Post by Thomas G. » Tue, 11 Jan 2005 23:01:11

Gerbrand van Dieijen coughed up:




Post by Aned » Sat, 09 Dec 2006 08:28:38

considering reuse at the source code level, what are the
characteristics that discriminates a model from a view or controller.
in other words, if some one gave me a peice of source code, is it
possible to tell whether it is a model or a view or a controller just
by reading through the source code?

the reason of having such a pattern is to facilitate the idea of
separation of concerns, it is comonly known that at the conceptual
level, it is possible to replace a model component with another one
that satisfy the model characteristics, but is that feasible at the
source code level?



Post by Lew » Sat, 09 Dec 2006 12:12:48

More or less, and it depends on the source code.

Consider what the terms "model", "view" and "controller" mean in this context.

"Model" is the business logic, so if you see a piece of code (be it class,
method or just a paragraph in a method), if it deals primarily with business
logic it's part of the "model".

"View" is the presentation, or the part with which the user interacts.
Typically this means the GUI (or command line), and the artifacts that
directly create the display and handle input. So if you see a form, dropdown,
button or the like that is part of the "view".

The "controller" has two main purposes - linking other components to each
other and managing navigation from screen to screen (or process flow module to
module). A controller component will invoke the correct model code in response
to a user input, say, or move the user from one page or screen to another.

Much real-world code intermingles these roles in a single code block or
artifact. You will probably encounter code that analyzes a screen input
(view), does some sort of business action such as a database update (model),
decides what screen to show next (controller) and moves the user to that
screen (view), all mixed together.

Well-written code will move these aspects into separate code blocks, usually
separate classes. For example, the Swing API includes JTable, a view
component, and TableModel, a model component. The JTable displays information
contained in the TableModel. One could display the information in some other
way than a JTable and still maintain its integrity as information in the

- Lew


Post by Ed » Sun, 10 Dec 2006 05:30:50

Aned skrev:

At least in the View will be easily distinct from both Controller and
Model at source code level (which, by the way, is the only level on
which MVC operates; at least there's no MVC at execution level ... ok,
it may/could exist at distribution level, but this is secondary to
source code concerns). The View will be the only one with large amounts
of HTML or Swing or println()s.

Here's a test for you: look at a few random classes from the model,
view, and controller subpackages here and see if think you could spot
the primary concern from the code if you couldn't see the package

.ed - Home of The Fractal Class Composition