我正在写一个小型的Java桌面应用程序，我正在使用MVC模式。我已经读过模型中应该如何保留逻辑，但是也有一些地方需要应用逻辑，但与GUI的功能完全相关。我还读过这些图层应该设计为允许“可插入”视图，这意味着如果您想将应用程序转变为命令行应用程序，您仍应该能够以最小的麻烦使用相同的模型。MVC中有多少GUI逻辑太多？
在我的应用程序，图像被显示在splitpane之一窗格。还有一个复选框，用于确定在用户调整窗格大小时是否动态调整图像大小。我觉得我有两个可能的解决方案：
当用户点击该复选框，则值将被存储在 模型。每当窗格调整大小时，该值将被验证 以查看图像是否应该缩放。由于复选框只涉及GUI的功能，所以我不会 在模型中存储值，并且我将在调整窗格大小时直接验证 复选框。
这是一个淡化的例子，但说明了我的问题。我在这里把逻辑分离到了极端吗？
“逻辑”可以细分为三个类别MVC：
在您的示例中，您听起来像是处于行为逻辑（即视图）。
并非所有的逻辑应该从视图中分离出来，但商业逻辑应该肯定。
我会提取UI相关的逻辑放到单独的类太，虽然，但对于Separation of Concerns。
分离问题的一个有效的经验法则是问自己以下问题：“如果需求改变（关于UI，验证等） - 我的应用程序的哪些部分/类将不得不改变？
演示模型：
独立的 代表呈现的状态和行为在界面中使用的GUI控件
我已经遇到这个问题很多次。想象一下你被要求做以下事情。
对照B必须出现，如果一天是星期一。
那么这是业务逻辑，不应该在视图中。该观点不应该关注这种类型的逻辑。视图只需要知道是否需要显示某个控件。因此，为了实现这一点，你可以有一个拥有所有需要的视图加了一个名为isBVisible财产此时，相应的属性的类。该属性isBVisible可能已从服务层填充，并返回视图所需的对象以显示数据。
第一个是真正的MVC。第二个不是。正如kostja所说，MVC对于关注的分离尤为重要。在较大的项目中，这对于跟踪发生在哪里至关重要。在较小的项目中（这是一次性的，或者不会用于生产环境，或者是内部工具或其他），这不是一个问题。