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?"