1

I am trying to understand MVC pattern. This question has been asked answered before, but I still can't understand.

Right now I am developing a simple Swing multithreaded program that downloads a various csv-files from DropBox and fills JTable with the data from these files.

I think that Model is represented by DropBoxDownloader class, FileParser class, some utility classes and that's all. View is simply my frame classes.

I am curious about Controller. What is it supposed to do? It feels like controller is supposed to be communication coordinator for Model View, but I can't understand it completely.

It is said that controller makes it easy to change both View and Model without changing entire application. Am I right?

Roman C
  • 49,761
  • 33
  • 66
  • 176
rsbn
  • 23
  • 3

2 Answers2

1

Because Swing uses a separable model architecture, discussed here, it may be easier to conceive of your application's model as an instance of the TableModel that supplies data to your JTable view. Because of the latency inherent in network access, you'll want to update your TableModel from another thread; Swingworker, illustrated here, is a good choice. More on Swing controllers may be found here.

Community
  • 1
  • 1
trashgod
  • 203,806
  • 29
  • 246
  • 1,045
0

I would not consider DropBoxDownloader or FileParser to be part of your model. Your model essentially represents your data. Your model is what gets persisted to a database. Generally, my model consists of POJOs (plain ole Java Objects), which is just a list of properties with getters and setters, and is serializable, so it can be sent over a network connection in a common format like JSON or XML. Anybody who can receive this information in a common format is free to do with it whatever they please, include deserializing into a different programming language. This is how complex systems can communicate with each other, and in some cases, not even knowing the other exists. I always keep my model in a separate package, and sometimes a separate project to enhance visibility and res-usability.

Your view should be able to exist without your data. It wont do everything you want it to do, but it should still be minimally operable as a shell. It should also be replaceable with a different view without loss of functionality. This means you shouldn't be mixing things like database queries in your View files, because you'll have to rewrite your queries for a new view.

Your controller is the glue which integrates your model and packages it up in an easy way to pass along to your view. In general, it does verbs (methods) to nouns (your model objects). I would consider FileParser (assuming it does what it says it does) and DropBoxDownloader to be functions of your controller.

Scott Schechter
  • 609
  • 6
  • 7
  • Thanks for answer, yet there is another question - there are a lot of guides that state that Model is a business-logic, not just data. What is the meaning of this? – rsbn Mar 07 '15 at 00:32
  • So, basically, Model stores data, View represents data and Controller make something happen to this data. Am I right? – rsbn Mar 07 '15 at 00:37
  • That is essentially correct. I generally keep my business logic in my controller functions, but you can utilize business logic in your model - for example: validation functions, clone methods, or simple calculated values that don't need to be persisted. If you put business logic in your model, its best to leave that logic self contained and not interacting with other components in your project. Those interactions should be done at the controller level. I would not have any instances of other objects unless they are field properties which are also part of the model. – Scott Schechter Mar 09 '15 at 14:39