How much GUI logic is too much in MVC?

Question

I'm writing a little Java desktop application and I'm using an MVC pattern. I've read about how logic should be kept in the model, but there are some places where logic has to be applied but is completely related to how the GUI functions. I've also read that the layers should be designed to allow a "pluggable" view, meaning if you wanted to turn the app into a command-line app, you should still be able to use the same model with minimal trouble.

In my app, an image is displayed in one pane of a splitpane. There's also a checkbox that determines whether or not the image is resized dynamically as the user resizes the pane. I feel like I've got two possible solutions:

1. When the user clicks the checkbox, the value would be stored in the model. Every time the pane is resized, that value would be verified to see if the image should be scaled.

2. Since the checkbox only relates to how the GUI functions, I wouldn't bother storing the value in the model, and I would verify the checkbox directly on resizing the pane.

This is a bit of a toned down example, but illustrates my problem. Am I taking the separation of logic to too much of an extreme here?

Answer 1

"logic" can be broken down into three categories for MVC:

• Validation logic - this should be in the model.
• Business / repository logic - this should be in the controller.
• Display and behavior logic - this should be in the view.

It sounds like, in your example, that you are in behavior logic (i.e., the view) at this point.

Answer 2

Not all logic should be separated from the view, but the business logic should definitely be.

I would extract the UI-related logic into separate Classes too though, but for the Separation of Concerns.

An effective rule of thumb for separation of concerns is to ask yourself the following question : "If a requirement changes (concerning UI, validation etc.) - which parts/classes of my application would I have to change then?"

Answer 3

Take a look at Presentation Model.

Presentation Model:

Represent the state and behavior of the presentation independently of the GUI controls used in the interface

I've come across this problem many times. Imagine you are asked to do the following.

Control B must appear if the day is Monday.

Well that is business logic and should not be in the View. The view should not be concerned with this type of logic. What the view just need to know is if a certain control has to be displayed or not. So in order to fulfill this you could have a class that has all the appropiate properties needed for the view plus a property called isBVisible. That property isBVisible could have been filled from a Service Layer and it returns the Object needed for the view to the display the data.

Answer 4

The first one is true MVC. The second is not. MVC is particularly important for, as kostja said, the Separation of Concerns. In larger projects this can be crucial for keeping track of what's going on where. In smaller projects (that are one-offs, or aren't going to be used in a production setting, or are in house tools, or whatever), it's less of an issue.