与Android设计模式相比，Java Swing MVC的比较

Question

我正在对各种平台上的设计模式进行小型研究，我在Java编程方面有先前经验。

在阅读这些帖子时：Android上的MVC模式和 Android中的MVC体系结构，
我有一个有趣的问题：为什么Java Swing MVC不能与Android开发模式相比？或者为什么我们不能说Android遵循MVC？（在整体“外观和感觉”的情况下）。

在一个答案中，有人将MVC澄清为：

• Model：要渲染什么

• View：如何渲染

• Controller：事件、用户输入

好的，现在我理解的是：

Java Swing MVC：

• 在Java swing MVC中，component类是视觉环境中所有属性的抽象类。有一个称为controls的专门关键字用于某些components，例如按钮、列表等。所以，所有控件和组件都是MVC中的一部分Model。

• Container继承component。并且有几个LayoutManagers定义布局和components在container中的位置。此外，还有必须注册的Listeners和相应的EventSources。所以，它们都是MVC中的View。

• 实现Listener interface methods类，在其中放置我们的主要逻辑，并为每个事件提供一些EventClasses。他们都是MVC中的Controller。

将所有这些示例放在一起形成一个图像；在swing MVC中，我们有：

Android设计模式（视觉化为MVC）：

• 我认为这里的widgets和controls是一样的。此外，还有其他一些EventSources，它们都作为Model。

• View包含viewgroups(也包括几种layouts)和Listener接口。它们都是MVC中的View部分。

• 同样的，在Swing MVC中，我们可以说Listener接口方法和活动都是Controller的一部分。

将所有内容放在一起形成一个图片; 在Android中，我们有：

根据上述比较，我认为以下相似之处：

• Container - 与View相同

• Layout managers - 与ViewGroup相同

• Listeners - 两种架构总体相同

• controls - 总体上与widgets相同

• Event delegation (将适当的Listener与Event源注册，然后实现Listener的方法) - 两种架构总体相同

那么，有人可以解释一下哪些因素使Android设计模式不同于Java Swing MVC模式？
或者如果您认为它们是不同的东西（在用于开发的设计模式的上下文中），请解释原因？

- Krupal Shah

---

你的问题需要一个较长的答案。我会试着回答，安卓在其MVC中对多线程提供了更多支持。例如，活动（Activities）正在实现命令处理器模式(Command Processor pattern)。道格·施密特(Doug Schmidt)在coursera上的POSA课程涉及了很多细节，不一定是在MVC中，但你可以从中获取更多信息。http://www.dre.vanderbilt.edu/~schmidt/cs282/PDFs/8-Services-and-IPC-parts-7-8-and-9.pdf - Fuhrmanator

此外，了解MVC变体的好文章是http://martinfowler.com/eaaDev/uiArchs.html。 - Fuhrmanator

@Fuhrmanator 当然可以...而且需要较长的回答...这就是我现在设置悬赏的原因。 - Krupal Shah

Answer 1

每个 Swing JComponent 都有一个 ComponentUI ，负责显示组件。虽然 JComponent 有一个绘制方法，但只有用户派生类直接使用它 - “标准”实现通常只是调用附加 UI 的绘制方法。这使得可以非常容易地插入各种外观和感觉的实现 - 不同的外观和感觉只提供不同的 ComponentUI。很明显，组件是“模型”，而 UI 是“视图”。Android 没有以非常明显的方式继承这种解耦。例如，它的 TextView 在类似 JLabel 的情况下似乎只是绘制可绘制对象。 painting drawables，而 JLabel 有 UI 。

然而，MVC方法并不仅仅在这里使用，在某些其他特定情况下，Android和Swing MVC非常相似。例如，Android的ListView具有与Swing JList类似的模型（ListAdapter和ListModel）。在这两种情况下，模型提供数据，而组件本身提供显示的可能性。可能的区别是，Swing具有更多具有这种解耦数据和表示的组件。JTable和JTree具有类似的模型，而Android没有提供这样的组件。根本没有树，TableLayout是一个被称为Swing中的GridLayout的东西，与JTable不相似。

无效和重绘的一般方法并没有太大的不同，在两个框架中只有专用的主线程才能接触组件。此外，Java和Android中的事件侦听器（可能是另一组“控制器”）非常相似，它们之间的所有差异可能只能被称为“微妙”。

Swing 和 Android 在容器和布局管理方面也非常相似，主要区别在于 Swing 可供选择的 LayoutManager 实现比 Android 的 ViewGroup 更多（例如 DatePicker 这样的类虽然是从 ViewGroup 派生出来的，但不是通用的布局管理器）。此外，Android 布局的一部分是使用 XML 编码的，而 Swing 通常只使用纯 Java。如果布局管理器也是“控制器”，响应调整大小或重新定位等事件，那么这部分工作也非常相似。但我不确定布局管理器是否真的是“控制器”，因为它们更多地更新视图而不是模型。

总体上，Swing 似乎更适用于大屏幕上显示的复杂 GUI，而 Android 更适合仅有少量可见组件的小屏幕，足够大，可以用手指操作而无需触控笔。

- Audrius Meškauskas

Answer 2

MVC 的主要特点是将三个组件的职责分开，分别为：

- Model 负责维护数据的内部表示。 - View 负责向用户显示数据并允许用户与其交互。 - Controller 负责根据用户对 View 的交互更新 Model，并确保 View 反映 Model 的当前状态。

根据 MVC 的定义严格程度，您也可以规定组件解耦的限制；例如，您可以断言 Model 不应该知道 View 或 Controller。然而，在大多数情况下，只需要表明这三个组件在软件中分别反映并符合上述一般职责即可被认为是足够的。

就将 MVC 映射到 Swing 和 Android 方面来看，我认为您遇到的主要问题是识别 Model。Model 不必是 UI 框架中不同类型的组件，它可以只是一个简单的类或一组封装所需数据的类。因此，在您将 Model 映射到小部件和控件时，我会认为这是不正确的：Model 只是表示向用户呈现的任何数据。因此，对于 Swing，我会将 MVC 组件映射如下：

• 模型: 任何代表您的数据的领域类，例如com.example.Order。
• 视图: 控件、容器和布局管理器。
• 控制器: 操纵模型并更新视图的事件监听器实现。

您可以在Swing中提出更严格的MVC实现，但以上可能是一个合理的映射。

Android UI框架比Swing更加限制，因为移动设备上的应用程序更受限制，Google希望它们以相当一致的方式运行，因此需要像Activity这样的类来表示用户需要执行的特定操作，并且与Activity和给定的View/ViewGroup之间有相对紧密的耦合。

即使如此，您仍然可以将Android组件映射如下：

• 模型: 任何代表您的数据的领域类，例如com.example.Order。
• 视图: Views和ViewGroups
• 控制器: Activity，假设您的Views的事件监听器代码是Activity的一部分，这通常是情况。

现在，你也可以认为上述内容更像是一种模型-视图-展示者模式，其中Activity扮演展示者的角色，但考虑到MVP可以被视为是MVC的更具体的一种形式，这并不一定无效化了MVC的映射关系。

- alphaloop