适用于没有数据层的桌面应用程序的MVC

Question

问题可能会非常棘手（因为它的性质或描述它的方式），所以在回答之前真正阅读它。

我有这个应用程序来写：
a）桌面应用程序; b）从数据库，文件或任何其他存储库的意义上说没有数据层（不需要保存，存储或加载数据）; c）应用程序将执行一些计算算法（遗传算法）; b）提供GUI，它将显示应用程序和计算结果的控件。

我想使用MVC模式，但我怀疑如何使用它。由于（例如）数据库（根据用户输入在执行期间生成数据）我没有数据层，因此我担心在此实现中使用MVC的方式。到目前为止，我已经提出了两种方法：

1. GUI是视图。 GeneticAlgorithm是控制器。 GeneticAlgorithmResults是Model（作为只存储数据的类）。基本流程：

   • 该视图发送用户输入到控制器;
   • 控制器正在处理用户输入并生成数据;
   • 控制器将生成的数据发送给模型;
   • 模型通知有关新数据的视图;
   • 视图拉取新数据并更新显示。

2. GUI是视图。 AppEngine是控制器。遗传算法和遗传算法结果是模型。现在我们有：

   • 视图发送用户输入到控制器;
   • 控制器正在处理用户输入并将控制信号发送到模型。
   • 模型更新其内部状态（生成新数据）;
   • 该模型通知控制器有关新数据;
   • 控制器将数据拉入模型;
   • 控制器处理数据;
   • 控制器将处理后的数据推送到视图;
   • 视图更新显示。

第一种方法似乎更直接，更喜欢MVC。问题在于某些逻辑必须位于模型中 - 决定何时通知模型，因为并非所有的数据更新都会显示，或者显示会随着数据集更新，而不是每一个小小的变化。这些决定将基于用户输入。在实际显示之前可能还需要额外的数据处理。这将在视图中。

另一方面，第二种方法似乎更复杂，看起来像传递许多消息来实现任务。但它完全控制了控制器的逻辑，并分离了视图，控制器和模型（这是MVC的主要目的）的职责。

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

Answer 1

从我对MVC的理解来看，第二个版本更像是严格的MVC范例。然而，我的一位非常聪明的老师曾告诉我，设计模式在那里给出了一套宽松的指导方针，并不一定意味着要遵循T.我认为，两者的混合是好主意。如果模型中有一些逻辑结束了，那么这不是世界末日，它只是意味着您必须更加小心地跟踪组件的分离。如果对MVC的一个小修改让你的生活更容易50％（更少的消息开销），那么它可能是一个好主意。

Answer 2

我肯定会更接近第二次执行的东西。是的，它看起来好像有更多的消息来回传递，但如果你的应用程序增长和变化，你会很高兴你已经建立了应用程序与小班。

考虑：逻辑处理诸如切换算法，执行算法和处理数据以进行查看等普通任务的逻辑在哪里？遗传算法对某种输入或起始数据进行操作，不是吗？你会从你的数据访问层得到这个。你不需要种子数据或初始化条件吗？关于将结果保存到文件并检索它们以供以后查看，那又怎么样？我认为一旦你的应用程序成熟，你需要做到这一点。预计首先您将使用基于文件的持久性。如果您感觉良好，以后可以升级到数据库。如果您针对抽象的数据持久层进行编码，那么以后不必更改业务逻辑以支持从文件到数据库的更改。

您应该使用策略模式来实现您的算法。这将允许您将遗传算法的解算器实现更改为其他算法，而无需更改每种算法的业务逻辑。

业务层将看到一个需要输入的ISolver，并且您将调用mySolver.Solve（）。您应该能够在不同版本之间切换，而无需更改业务层逻辑（Open Closed Principle）。业务逻辑与算法交互方式的唯一区别应该在构造函数中，甚至在那里，您应该考虑使用Factory模式。