aspose file tools*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes This is MVC. Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "This is MVC." Watch "This is MVC." New topic
Author

This is MVC.

Brad Smith
Greenhorn

Joined: Jul 13, 2003
Posts: 5
I have written a small MVC application (thanks to Andrew Monkhouse for his suggested modifications). This application does nothing more than enable the end user to enter a temperature in Fahrenheit or Celcius, and then outputs both types of temperature into output textboxes. This application is not directly related to the SCJD application, but the concepts can be used in the SCJD.
There are 3 source files (Model.java, View.java, Controller.java). Cut and paste them into your favourite editor, then compile, and run (Compile Model.java first, View.java second, Controller.java third, then run Controller.class).
Feel free to make any suggestions/comments/note other ways of implementing MVC...
-----------------------------------------------

------------------------------------------------

------------------------------------------------

-----------------------------------------------
Brad Smith
Max Habibi
town drunk
( and author)
Sheriff

Joined: Jun 27, 2002
Posts: 4118
Nicely Done
M


Java Regular Expressions
John Smith
Ranch Hand

Joined: Oct 08, 2001
Posts: 2937
I have a few comments:
  • The use of Sun's java.util.Observable and java.util.Observer is certainly a valid option, but it's not without the drawbacks. Most notably, since java.util.Observable is a class and your Model must extend java.util.Observable, it fixes the position of your Model in the class hierarchy. That is, your model cannot extend any other class. Additionaly, the java.util.Observable-java.util.Observer pair is somewhat heavy and inflexible (since it is in the classes that you can't modify). For these reasons, some people prefer to create their own, custom version of Observer-Observable, which is a very straighworward thing to do.
  • In your code, the constructor for the View takes a reference to Model, which essentially couples the View with the Model and constitues a so called "pull" model. That is, the View quires the Model and pulls the data that it needs. Again, this is a valid option, but there is also an alternative. Instead of View pulling data from the Model, you can instead "push" it from the Model down to the registered Views. That way, your Views are completely decoupled from the Model and don't need to change when the Model code changes.
  • Good job with the View-Controller and the event listeners, -- everything is nicely encapsulated and coupling is minimized.

  • Jim Yingst
    Wanderer
    Sheriff

    Joined: Jan 30, 2000
    Posts: 18671
    Cool, it's nice to have a short concrete example of this stuff to talk about. Good job.
    A few comments:
    I feel compelled to point out that it's "Celsius", not "Celcius".
    Eclipse felt compelled to point out that you have a number of unused imports, especially in the Model. Also as a matter of style, frame.EXIT_ON_CLOSE should probably be JFrame.EXIT_ON_CLOSE so it looks less like an instance field.
    On a more substantial note, I find I dislike seeing the controller code using ActionListener - that feels too closely tied to Swing/AWT. What If I want to change Controller to use an HTML-based view from a JSP instead? Or WML for a wireless app? These guys shouldn't have anything to do with ActionEvent, IMO. I'd prefer to have all the view's hook methods use a more generic interface, like Runnable. So my controller would say

    and the code in View would be

    What do folks here think of this approach? Good, or one level of abstraction too many?
    Naturally Eugene's comments may be incorporated as well. Perhaps we could see several complete version of the code for this application, to more fully illustrate the different approaches preferred by Eugene, Mark S, etc.


    "I'm not back." - Bill Harding, Twister
    Brad Smith
    Greenhorn

    Joined: Jul 13, 2003
    Posts: 5
    Thanks for the replies.
    The use of Sun's java.util.Observable and java.util.Observer is certainly a valid option, but it's not without the drawbacks...

    The reason I used Observer/Observable was to simplify my code (as suggested by Andrew Monkhouse). I realize that it may not work in every situation.

    ...you can instead "push" it from the Model down to the registered Views. That way, your Views are completely decoupled from the Model and don't need to change when the Model code changes

    I realize that by having a reference to the model inside the view, that there is more coupling. However (as suggested by Andrew Monkhouse),"...if you decide to allow views to access static data in the model directly (such as your database schema for instance) then your view would need to have a reference to the model (or to an interface that the model implements)."

    On a more substantial note, I find I dislike seeing the controller code using ActionListener - that feels too closely tied to Swing/AWT. What If I want to change Controller to use an HTML-based view from a JSP instead? Or WML for a wireless app? These guys shouldn't have anything to do with ActionEvent, IMO. I'd prefer to have all the view's hook methods use a more generic interface, like Runnable.

    I believe that this is a judgement call, I would be interested to hear what other people would do in their SCJD project.

    Brad Smith
    John Smith
    Ranch Hand

    Joined: Oct 08, 2001
    Posts: 2937
    JY: I feel compelled to point out that it's "Celsius", not "Celcius".
    It would be nice to have an Eclipse plug-in that would detect such a gruesome violation of the JLS.
    JY: On a more substantial note, I find I dislike seeing the controller code using ActionListener - that feels too closely tied to Swing/AWT.
    I didn't think there was a way to avoid it, but there is, indeed, looking at your sample code. Very nice.
    BS (presumably quoting AM) : if you decide to allow views to access static data in the model directly (such as your database schema for instance) then your view would need to have a reference to the model (or to an interface that the model implements).
    Not really. It doesn't matter if the data is static or not, -- you can push anything down to the views, in any form you want. The real disadvatage of the "push" is that there may be a more frequent and excessive amount of data transfer between the Model and the Views, whereas with the "pull", the Model just sends a ping and the Views retreive the needed data selectively, using the Model state quiry methods.
    Andrew Monkhouse
    author and jackaroo
    Marshal Commander

    Joined: Mar 28, 2003
    Posts: 11476
        
      94

    Hi,
    Good points by everybody.
    Eugene: The use of Sun's java.util.Observable and java.util.Observer is certainly a valid option, but it's not without the drawbacks.

    Agreed. But unless you are being affected by one of the drawbacks you mentioned earlier, then for the assignment I would recommend using Sun's provided classes. After all, we are recommended to use standard solutions where they exist.
    In both this and the other MVC example Brad posted, the Model has not extended any other classes, so there is no problem extending Observable. I found that for my assignment, I did not need (or want) to have my model extend any other class either. My model had an instance of a class that implemented DatabaseInterface - my model was not a DatabaseInterface itself. To me this is logical, because the model "represents enterprise data and the business rules that govern access to and updates of this data" (from the Sun MVC blueprint). Therefore the Model may not necessarily just be a facade to the database, but may have totally different methods to those provided by the database, where these methods may indicate the business function (e.g. "bookFlight()") and/or have additional business rules behind the methods.
    BS (presumably quoting AM) : if you decide to allow views to access static data in the model directly (such as your database schema for instance) then your view would need to have a reference to the model (or to an interface that the model implements).

    Yep, that was me. What I was trying to suggest was a hybrid model that does both "push" and "pull". The model could push out any changes to the data being modeled, but views can also pull in any static data. The example I gave was pulling down the schema. You could push out the schema to all Observers, but this could be unnecessary overhead - the schema should not be changing in the middle of your application. So you could pull that down (possibly even in your constructor - so you would not need to keep a reference to your model later) but still get changes to the data pushed to you.
    Jim: I feel compelled to point out that it's "Celsius", not "Celcius".
    Eugene: It would be nice to have an Eclipse plug-in that would detect such a gruesome violation of the JLS.

    Bwahahaha.
    If we are going into spellings, can someone please change all the computer languages that spell Colour as Color? :roll:
    Regards, Andrew


    The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
     
    I agree. Here's the link: http://aspose.com/file-tools
     
    subject: This is MVC.