When using JavaFX, I have been applying the MVC architecture but getting some online advice that MVC is "dead" and not to use it.
Working thru books and when looking up Oracle's demos and samples for guidance, the codes that used to be in Controller are now together with the Modal and View i.e. the user interacts with the GUI and the setOnAction bits are all in the same class
In eclipse, with the e(fx)lipse and Scene Builder add-ons, the MVC architecture is still used and I can drag-and-drop with Scene Builder to create the .fxml document
AhFai Chan wrote:Working thru books and when looking up Oracle's demos and samples for guidance, the codes that used to be in Controller are now together with the Modal and View i.e. the user interacts with the GUI and the setOnAction bits are all in the same class
Yes, it's quite common for Swing code (and now JavaFX code too) to have controller code and GUI code intermingled. Or at least, to appear that way; for example code creating a GUI component is obviously part of the View, but then you might add a listener to the GUI component. The code inside that listener is part of the Controller, as it's going to interact with the Model or the View or both, but it does appear to be in the same class. You can make the point that the listener code is in an anonymous inner class, which is separate from the class which contains it, but when you change the anonymous inner class to a lambda expression then it's harder to believe that.
You could be fastidious about MVC and require that the listener should do nothing but call some code which is in a class defined as "Controller" code in the architecture. For example, create a separate class which implements whatever listener and then use an instance of that class. Personally I haven't done that very much, I just mentally note that the listener code is part of the Controller.
Also, a lot of the tutorials were written before the developers of Java were really into architecture; some of the older ones include bad practices (like extending JFrame) which are still imitated by beginners who read those tutorials. Well-architected code takes more work to write and results in a lot more classes. For example consider Java's first try at date-handling: there was basically Date, Calendar, and TimeZone and a few other supporting classes. When the architects got through redesigning that horribly flawed set of classes they produced the java.time package with its 15 classes along with four other packages for non-standard time systems, date and time formatting, working with date and time components, and time zones. I count 39 classes in total plus a non-trivial number of interfaces and enums.
Thanks, you have made the whole architecture more palatable for me. I am getting used to it and I will really just do what works... even if the coding does not strictly conform to the architecture.
The reason Model/View/Controller architecture became so popular was that it provided Separation of Concerns. This makes creation and maintenance easier/cheaper/faster because when you need something, you don't have to launch a "treasure hunt" all over the application source code tree to find out where things are done.
Pure MVC is actually pretty much useless. All MVC is responsible for is ensuring that the data presented in the View matches its corresponding values in the Model and vice versa. At some point in the Real World, however, you're going to need something to load up the model and/or take what's in it and Do Something with it - business logic and/or persistence.
What you call that extra stuff is up to you. Ideally, that's all going to be in its own set of classes and the Model classes, the View classes and the Controller classes should be distinct. That maximizes your flexibility, since true MVC doesn't require a 1/1 relationship between Models and Views (my favorite example is a display where one or Models serve as the source data for simultaneous spreadsheet and chart Views). Plus Separation of Concerns also means that code is more likely to be re-usable and that you are more likely to be able to use an Inversion of Control framework (such as Spring) to wire together components.
There are basically 2 ways to construct a View. Some systems, such as JavaServer Faces, Android, and the archetypal Macintosh™ GUI system allow you to define the View via a static templating facility. That is, you have a Domain Specific Language (View Definition Language - VDL or View Template Language - VTL) that is designed to speed the graphic design, make the layout more obvious, and allow compile-type checking of the definition. Other systems, such as Swing, require you to do it all the hard way. The net result, however is the same.
A VDL template virtually mandates Separation of Concerns, since it's a completely separate language from the language used by the Model code. Some horrible examples why templates are preferable can be seen in legacy ASP and PHP web pages. They give IDEs fits, and since they're doing 2 different things, the code is twice as long. For frameworks where GUI elements are built in code, it's still a good idea to keep Model and View code apart, however. As I said, it's more flexible and you are less likely to have annoying coupling effects between GUI and Model functions.
There is no one-size-fits-all solution, When your components are small and simple, it's more annoying than useful to split everything out in excruciating detail. But as complexity grows, it's nice to be organized.
Now you'll have to excuse me. I need to ransack my office and try and find something that doesn't have a standard place to keep it.
The secret of how to be miserable is to constantly expect things are going to happen the way that they are "supposed" to happen.
You can have faith, which carries the understanding that you may be disappointed. Then there's being a willfully-blind idiot, which virtually guarantees it.