model-view-controller - 用于没有数据层的桌面应用程序的 MVC

Question

问题可能很棘手(因为它的性质或我描述它的方式)，所以在回答之前请认真阅读。

我有这个应用程序要写:
a) 桌面应用程序；
b) 没有数据库、文件或任何其他存储库意义上的数据层(无需保存、存储或加载数据)；
c)应用程序将实现一些计算算法(遗传算法)；
b) 提供 GUI，它将显示应用程序和计算结果的控件。

我正在考虑使用 MVC 模式，但我怀疑如何使用它。由于我在(例如)数据库方面没有数据层(数据是在执行过程中根据用户输入生成的)，因此我担心在此实现中使用 MVC 的方式。到目前为止，我提出了两种方法:

GUI 是 View 。遗传算法是 Controller 。 GeneticAlgorithmResults 是模型(作为仅存储数据的类)。基本流程:

View 将用户输入发送到 Controller；

Controller 正在处理用户输入并生成数据；

Controller将生成的数据发送给Model；

Model 通知 View 新数据；

View 拉取新数据并更新显示。

GUI 是 View 。 AppEngine 是 Controller 。遗传算法和遗传算法结果是模型。现在我们有:

View 将用户输入发送到 Controller；

Controller 正在处理用户输入并向模型发送控制信号。

模型更新其内部状态(生成新数据)；

模型通知 Controller 新数据；

Controller 拉取数据到模型；

Controller 处理数据；

Controller 将处理后的数据推送到 View ；

View 更新显示。

第一种方法似乎更直接，更像 MVC。问题是模型中必须有一些逻辑 - 决定何时通知模型，因为不会显示所有数据更新，或者可能会使用数据集而不是每一个微小的变化来更新显示。这些决定将基于用户输入。更重要的是，在实际显示之前可能需要对数据进行一些额外的处理。这将在 View 中。

另一方面，第二种方法似乎更复杂，看起来要传递很多消息来完成任务。但是它将Logic的完全控制权交给了Controller，并将View、Controller和Model的职责分开(这是MVC的主要目的)。

您会推荐哪种方法？或者，也许我应该将它们混合使用并使用第一种方法架构和第二种方法的通信流？还是一些不同的设计？

Answer 1

从我对 MVC 的理解来看，第二个版本更像是严格的 MVC 范式。然而，我的一位非常聪明的老师曾经告诉我，设计模式的存在是为了提供一套松散的指导方针，并不一定要遵循 T。

在我看来，两者结合是个好主意。如果某些逻辑最终出现在模型中，这并不是世界末日，它只是意味着您必须更加小心地跟踪组件的分离。如果对 MVC 的一个小修改让你的生活轻松了 50%(更少的消息开销)，那么这可能是一个好主意。