我正在编写一个小的Java桌面应用程序，我使用MVC模式。我已经了解了如何在模型中保留逻辑，但是有些地方必须应用逻辑，但与GUI的功能完全相关。我还读到，这些层应该被设计成允许"可插拔"视图，这意味着如果你想把应用程序变成命令行应用程序，你仍然应该能够使用相同的模型，麻烦最少。
在我的应用程序中，图像显示在拆分窗格的一个窗格中。还有一个复选框，用于确定是否在用户调整窗格大小时动态调整图像大小。我觉得我有两个可能的解决方案:
-
当用户单击复选框时，该值将存储在模型。每次调整窗格大小时，都会验证该值查看图片是否需要缩放
-
由于复选框只与GUI功能有关，所以我不会将值存储在模型中，我将验证
MVC的"逻辑"可以分为三类:
- 验证逻辑-这应该在模型中。
- 业务/存储库逻辑——这应该在控制器中。
- 显示和行为逻辑-这应该在视图中。
在您的示例中，听起来您此时处于行为逻辑(即视图)中。
不是所有的逻辑都应该从视图中分离出来，但是业务逻辑绝对应该这样。
我也会将与ui相关的逻辑提取到单独的类中，但是为了关注点分离。
一个有效的分离关注点的经验法则是问你自己下面的问题:"如果一个需求改变了(关于UI，验证等)——我的应用程序的哪些部分/类需要改变?"看一下Presentation Model
<<p> 表示模型/strong>:我已经遇到这个问题很多次了。假设你被要求做以下事情。独立于表示的状态和行为界面中使用的GUI控件
控件B必须在当天为星期一时出现。
那是业务逻辑，不应该在视图中。视图不应该关注这种类型的逻辑。视图只需要知道某个控件是否需要显示。为了实现这个，你可以有一个类，它拥有视图所需的所有适当属性，加上一个名为isBVisible的属性。属性isBVisible可以从服务层填充，它返回视图显示数据所需的对象。
第一个是真正的MVC。第二个则不然。正如kostja所说，MVC对于关注点分离尤为重要。在较大的项目中，这对于跟踪在哪里发生了什么是至关重要的。在较小的项目中(一次性的，或不会在生产环境中使用的，或内部工具，或其他)，这不是一个问题。