• Post Reply Bookmark Topic Watch Topic
  • New Topic

Large scale MVC application  RSS feed

 
Brad Hoff
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi all,

I'm writing a large scale application using MVC architecture.

I'm happy with basic MVC in general, but all the examples seem to only use one dialog or one mvc group (model, view, controller).


What would the structure look like if I were to have an application with several components and dialogs?

Would there be a main MVC group, and then when certain events are sent to the controller, (e.g. a button is pressed on the control panel to open an options dialog) it initialises the MVC group for that dialog?

How would the information (options) be passed back through the application? Would it just pass the model back?


Thanks in advance!
 
Tim Holloway
Bartender
Posts: 18531
61
Android Eclipse IDE Linux
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Welcome to the Ranch, Brad!

One of the reasons why MVC is the pre-eminent way of architecting GUI apps is that not only does it provide a strong Separation of Concerns, it provides a many-to-many relationship between Views and Models. My favorite example is a View that contains a Table and a Pie chart, both based on the same Model, but I've done a lot of apps where there were multiple models contributing to a single View.

MVC doesn't merely apply at the top-level. Most commonly, the View breaks down into multiple sub-views (for example, window, input text, radio button group, more input text), which map to corresponding sub-models. Then you likewise have a tree of Controllers in a parent-child relationship to bind corresponding sub-views and sub-models together.

A desktop app typically has a main window, which would predicate a top-level Controller to go with it. Then child windows, dialogs, etc. would hang off of it.

It should be noted that in its purest sense, MVC is nothing but Models, Views, and Controllers, and all the Controllers do is ensure that the Models and Views are kept in sync with each other - changes to Views update their models, changes to Models update their views. In the Real World, however, you generally want to do something useful with the data in those models, so somewhere you have to hang business logic off of it. Stuff like persistence, processing, and, of course, the creation and destruction of child MVC systems such as Dialogs, Toolbars and Menus. Typically, the business logic is bound to the Model side of things, but the MVC paradigm doesn't actually specify it, since, like I said, MVC doesn't really get into that part of the application.
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!