将MVC模式应用于现有应用程序

Question

这是The MVC pattern and SWING的后续问题。我试图在现有的代码片段中实现MVC模式。现有代码创建一个JFrame，它既充当视图又充当控制器。 JFrame有一个表，表的模型是自定义数据模型的适配器。每当用户执行操作时，都会通过执行以下操作来更新模型：

CustomDataTableModel cdtm = (CustomDataTableModel) DataTable.getModel();
CustomDataModel cdm = cdtm.getModel();
cdm.delete(1);

我试图想象它当前是如何工作的，但我也想象了我如何想象与未来控制器和模型的关系应该是。

现在，我的问题是我是否可以像现在一样继续使用模型？我可以实现以下内容并仍“坚持”MVC模式吗？

1. 用户选择表格中的元素，然后点击删除按钮。
2. 视图将操作委派给控制器。
3. 控制器通过视图上的访问者访问表，并执行更新。
4. 模型在更新时会通知JTable它已被更改。

如果视图中的任何其他组件显示表中的数据，则可以通过在JTable的表模型上注册侦听器来解决此问题。

更新1

我一直在考虑根据MVC模式的现有代码，并且我重新绘制了一些关系。关键是控制器是视图的行为，因此控制器在用户执行操作时更新模型，并且视图侦听模型中的更改。但是，MVC模式中的任何内容都不会阻止视图通过tablemodel监听模型 - 对吗？



现在，用户点击添加按钮。视图通知控制器已单击添加按钮，控制器通过调用模型上的某个方法来处理创建新项目。视图在模型上注册为侦听器（通过表模型）并更新其视图。如果控制器需要处理禁用或锁定字段，则控制器也可以是模型上的监听器。我没有达到MVC的全部意义;关注点分离？据我所知，我甚至引入了适配器模式，以便从模型中更多地分离视图？已经很晚了，我累了，所以这可能是有道理的原因： - ）

Answer 1

一般来说，我会建议你：

• 看看JGoodies Binding， 它不是MVC而是使用 “PresentationModel”模式 在我看来，这更好 适应整个应用而不是 MVC（我认为适合 仅限个别小部件）。这应该 解决你的问题 Domanin模型和TableModel
• 如果您的应用程序只有表格， 然后GlazedLists也成了 很有道理：它也会孤立 您的域模型 TableModel（但它没有强制执行 任何全球模式，MVC或PM）

关于您显示的当前设计，我建议查看向控制器询问Action 查看将分配给删除按钮。然后控制器可以作用于域模型。

Answer 2

快速混乱，唉，由于缺乏分离，代码库已经混乱了。

我建议将不同的组件迁移到干净，简单的MVC设计中。这样的成分（这是目前一个视图，控制器和模型都混在一起）然后以清洁的方式进行分离，但是你会再有如何处理控制器和模型的难度？   作为临时解决方法，您将被迫将所有者视图指定为控制器，因此所有者可能会承担更多责任。我认为，这是一个合适的解决方法，因为你最终会越来越多的元件分离成MVC设计，而且也控制器最终将成为重构为好。观点

换句话说：

1. 对于大型应用程序，请识别一个小组件。 （低悬的果实）。
2. 确定有效控制该组件的代码。在这种情况下，这可能是另一个“视图”类。
3. 将步骤1中确定的组件分离为干净的设计。
4. 将步骤中标识的所有者（视图）显式配置为新重构组件的控制器。
5. 重复，直到所有视图和控制器之间清晰分离。

小心确保应用程序在上面的每个“步骤4”结束时仍在工作，否则，你会发现自己处于一个混乱状态，只是需要更长时间才能修复。 （即使最终结果很好也很干净，你可能错过了截止日期）。

记

请它可能很难在第一次提取从代码中的“模式” - 控制器和视图将是最容易分开，但最终，该车型将变得更加容易分离为好。每当您设法提取模型时，请编写单独测试该模型的单元测试。

一套精心编写的单元测试将有助于确保应用程序继续具有明确的关注点分离。 （如果问题没有分开，那么单元测试变得非常困难），因此单元测试方法可以作为激励因素。

我希望这是有道理的。