5

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

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

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

  1. GUI 是视图。遗传算法是控制器。GeneticAlgorithmResults 是模型（作为仅存储数据的类）。基本流程：

    • View 将用户输入发送到 Controller；
    • 控制器正在处理用户输入并生成数据；
    • Controller将生成的数据发送给Model；
    • Model 通知 View 新数据；
    • 视图拉取新数据并更新显示。

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

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

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

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

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

4

2 回答 2

2

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

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

于 2009-04-21T00:26:13.937 回答
1

我肯定会选择更接近第二个实现的东西。是的，看起来确实有更多的消息来回传递，但是如果您的应用程序增长和变化，您会很高兴您已经使用小类构建了应用程序。

考虑一下：处理普通任务的逻辑在哪里，比如在算法之间切换、执行它们和处理数据以供查看？

遗传算法对某种输入或起始数据进行操作，不是吗？你会从你的数据访问层得到这个。您不需要种子数据或初始化条件吗？将您的结果保存到文件并检索它们以供以后查看怎么样？我认为一旦您的应用程序成熟，您就需要这样做。期望一开始您将使用基于文件的持久性。如果您觉得可以，稍后您可以升级到数据库。如果您针对抽象的数据持久层进行编码，则以后不必更改业务逻辑来支持从文件到数据库的更改。

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

业务层将看到一个接受输入的 ISolver，您将调用 mySolver.Solve()。您应该能够在不同版本之间切换，而无需更改您的业务层逻辑（开放封闭原则）。业务逻辑与算法交互方式的唯一区别应该在构造函数中，即使在构造函数中，您也应该考虑使用工厂模式。

于 2009-04-21T01:09:09.607 回答