• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Java FX - MVC x MVVM

 
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello,
I have a question about architectire of application. Lets say I have a model class that contains 5 observableCollections. I have two threads that change this model very often. Then I have controller - where I have: listView.setItems(modelClass.getObservableCollection()); So when something changes in model class - it also changes automatically view. Or when client wants to remove and item from list - controller removes it from model and it automatically affects view.
Is it still MVC or MVVM?

I tried to find the differences between MVVM and MVC, but what I found out is:

MVVM - View and ModelView are binded together - so view is automatically updated
MVC - controller updates model and then it may change the view or he may change view.

So when observableList is updated - view is updated too.

So I understand MVVM like that view updates thanks to properties in modelview.

I used MVC with spring and it is really easier, because you dont have observableCollections and etc... everything is done by controller... but not in this case...

Thank you!
 
Rancher
Posts: 1171
18
IntelliJ IDE Hibernate Firefox Browser MySQL Database Spring Tomcat Server Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I would consider the applications I have written in JavaFx still MVC and not MVVM.
I always use springBoot together with javaFx, simply because I like how easy it is to use.
How my applications work:

But I most add, that I don't use my contoller to create the view, I write my views scenebuilder and then do the needed changes in the fxml.
In the fxml the controler is binded with the view. My observable lists are filled with data my controller get's from the repository, who get's it in his turn from the db.
When a user clicks on a button to remove for example an item from a list, the change dosn't only need to be made in the observable list, the controller also needs to call the repository and remove the item from the db, otherwise next time the page loads it's still there... I hope it's clear enoug, cause I find it hard to explain, but I consider my application an mvc patern like described on http://www.tachenov.name

Another variation of the MVC pattern is often seen in web frameworks, such as Spring MVC. In this case, the model is a simple DTO (data transfer object), basically a hash map, easily serialized into JSON or something. The controller prepares the model and sends it to the view. Sometimes it’s just a matter of passing the object inside a single process, but sometimes the model is literally sent over the wire. This is different from a typical desktop observer approach where the controller doesn’t even know anything about the view. To keep this coupling loose, the controller often doesn’t send the model directly to the view, but rather sends it to the framework which then picks up an appropriate view and passes the model to it.

What makes this pattern especially confusing is that the model is no longer the domain model. Rather we have two models now: the M part of the MVC pattern is the data transfer model, whereas the controller acts on the domain model (maybe indirectly through a service layer), gets back the updated data, then packs that data into a DTO and passes it to the view to display. This very idea of the data transfer model is exactly what makes this pattern so suitable for web applications, where the controller may not even know in the advance what to do with the data: you may have to wrap it into HTML and send to the browser, or maybe you serialize it into JSON and send it as a REST response.

Either way, one problem with MVC is that view is too complicated. One thing about UI is that it tends to be both heavyweight and volatile, so you usually want to keep it as clean as possible. In MVC, view doesn’t only display data but it also has the responsibility of pulling that data from the model. That means the view has two reasons to change: either requirements for displaying data are changed or the representation of that data is changed. If the model is the domain model, then it’s especially bad: the UI should not depend on how data is organized in the domain model. If the model is a DTO model, then it’s not that bad, but it still can be changed, for example, to accommodate the need for a new view (or a REST client). Still, MVC is often the best choice for web applications, and therefore is the primary pattern of many web frameworks.

One major disadvantage of MVC is that the view is not completely devoid of logic, and therefore it can be hard to test, especially when it comes to unit tests. Another disadvantage is that you have to reimplement all that logic if you’re porting your view to another tech (say, Swing to JavaFX).

 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic