问题可能很棘手（因为它的性质或我描述它的方式），所以在回答之前请仔细阅读本文。
我要编写这个应用程序：
a) 桌面应用程序；
b) 没有数据库、文件或任何其他存储库意义上的数据层（不需要保存、存储或加载数据）；
c) 应用程序将实现一些计算算法（遗传算法）；
b) 提供 GUI，它将显示应用程序和计算结果的控件。
我正在考虑使用 MVC 模式，但我怀疑如何使用它。 由于我没有（例如）数据库意义上的数据层（数据是在执行期间根据用户输入生成的），因此我担心在此实现中使用 MVC 的方式。 到目前为止，我已经想出了两种方法：
-
GUI 是视图。 遗传算法是控制器。 GeneticAlgorithmResults 是模型（作为仅存储数据的类）。 基本流程：
- 视图将用户输入发送到控制器；
- 控制器正在处理用户输入并生成数据；
- 控制器将生成的数据发送给模型；
- 模型通知视图新数据；
- 视图提取新数据并更新显示。
-
GUI 是视图。 AppEngine 是控制器。 遗传算法和遗传算法结果是模型。 现在我们有：
- 视图将用户输入发送到控制器；
- 控制器正在处理用户输入并向模型发送控制信号。
- 模型更新其内部状态（生成新数据）；
- 模型向控制器通知新数据；
- 控制器将数据拉入模型；
- 控制器处理数据；
- 控制器将处理后的数据推送到View；
- 视图更新显示。
第一种方法似乎更直接，更像 MVC。 问题是模型中必须有一些逻辑 - 决定何时通知模型，因为并非所有数据更新都会显示，或者可能会使用数据集更新显示，而不是每次微小的变化。 这些决定将基于用户的输入。 此外，在实际显示之前可能需要对数据进行一些额外的处理。 这将在视图中。
另一方面，第二种方法似乎更复杂，并且看起来要传递很多消息来完成任务。 但它将逻辑的完全控制权交给了控制器，并将视图、控制器和模型的职责分开（这是 MVC 的主要目的）。
您会推荐哪种方法？ 或者也许我应该将它们混合并使用第一种方法架构和第二种方法的通信流？ 或者有什么不同的设计？
Question might be tricky (because of its nature or my way of describing it), so really read this before answering.
I have this app to write:
a) desktop app;
b) no data layer in sense of database, files or any other repository (no need to save, store or load data);
c) app will have some computation algorithms implemented (Genetic Algorithm);
b) provides GUI which will display controls for app and computations results.
I am thinking about using MVC pattern but I have doubts how to use it. Since I have no data layer in sense of (for example) database (data is generated during execution based on user input) I am concerned about way of using MVC in this implementation. So far I have came up with two approaches:
-
GUI is the View. GeneticAlgorithm is the Controller. GeneticAlgorithmResults is the Model (as class that only stores data). Basic flow:
- The View sends user input to the Controller;
- The Controller is processing user input and generates data;
- The Controller sends generated data to the Model;
- The Model notifies the View about new data;
- The View pulls new Data and updates the display.
-
GUI is the View. AppEngine is the Controller. GeneticAlgorithm nad GeneticAlgorithmResults are the Model. Now we have:
- The View sends user input to the Controller;
- The Controller is processing user input and sends control signals to the Model.
- The Model updates its internal state (generates new data);
- The Model notifies the Controller about new data;
- The Controller pulls data to model;
- The Controller processes data;
- The controller pushes processed data to the View;
- The View updates the display.
First approach seems to be more straightforward and more like MVC. The problem is that some logic would have to be in the Model - decide when to notify the model as not all data updates will be displayed, or maybe display will be updated with the sets of data not every little change. Those decisions will be based on user input. Whats more some additional processing of the data may be needed before actual display. This would be in the View.
On the other hand second approach seems to be more complicated and looks like to much messages are being passed to achieve the task. But it gives full control of Logic to the Controller and separates responsibilities of the View, the Controller and the Model (which is the main purpose of MVC).
Which approach would you recommend? Or maybe I should mix them and use first approach architecture with communication flow from second approach? Or some different design?
发布评论
评论（2）
从我对MVC的理解来看，第二个版本更像是严格的MVC范式。 然而，我的一位非常聪明的老师曾经告诉我，设计模式是为了提供一套松散的指导方针，并不一定要遵循T。
在我看来，两者的结合是一个好主意。 如果某些逻辑最终出现在模型中，这并不是世界末日，它只是意味着您必须更加小心地跟踪组件的分离。 如果对 MVC 的一个小修改可以让您的生活轻松 50%（消息开销更少），那么这可能是一个好主意。
From my understanding of MVC, the second version is more like the strict MVC paradigm. However, one of my very intelligent teachers once told me that the design patterns are there to give a loose set of guidelines and are not necessarily meant to be followed to the T.
In my opinion, a mix of both is a good idea. If some logic ends up in the Model, it isn't the end of the world, it just means that you have to be more careful about keeping track of the separation of your components. If a small modification to MVC makes your life 50% easier (less message overhead), then it is probably a good idea.
我肯定会选择更接近第二个实现的东西。 是的，看起来确实有更多的消息来回传递，但是如果您的应用程序增长并发生变化，您会很高兴您使用小类构建了应用程序。
考虑一下：处理日常任务（例如在算法之间切换、执行算法以及处理数据以供查看）的逻辑在哪里？
遗传算法对某种输入或起始数据进行操作，不是吗？ 您可以从数据访问层获取此信息。 您不需要种子数据或初始化条件吗？ 将结果保存到文件并稍后检索以供审核怎么样？ 我认为一旦您的应用程序成熟，您就需要这样做。 预计您首先将使用基于文件的持久性。 如果您愿意，稍后可以升级到数据库。 如果您针对抽象数据持久层进行编码，则以后无需更改业务逻辑即可支持从文件到数据库的更改。
您应该使用策略模式来实现您的算法。 这将允许您将求解器的实现从遗传算法更改为其他算法，而无需更改每个算法的业务逻辑。
业务层将看到一个接受输入的 ISolver，您将调用 mySolver.Solve()。 您应该能够在不同版本之间切换，而无需更改业务层逻辑（开闭原则）。 业务逻辑与算法交互方式的唯一区别应该在构造函数中，即使在那里，您也应该考虑使用工厂模式。
I would definitely go with something closer to the second implementation. Yes, it does seem like more messages passed back and forth, but if your application grows and changes, you will be happy that you've built the application with small classes.
Consider: Where is the logic to handle mundane tasks like switching between algorithms, executing them and processing the data for viewing?
Genetic algorithms operate on some kind of input or starting data, don't they? You would get this from your data access layer. Don't you need seed data or initialization conditions? What about saving your results to file and retrieving them for review later? I would think that you need to do this once your application matures. Expect that at first you will use file based persistence. If you're feeling up to it, later you can upgrade to a database. If you code against an abstracted data persistence layer, you won't have to change business logic later to support the change from file to database.
You should use the strategy pattern to implement your algorithms. This will allow you to change the implementation of your solver from genetic algorithm to your other algorithms without having to change the business logic for each algorithm.
The business layer will see a ISolver that takes inputs, and you will call mySolver.Solve(). You should be able to switch between the different versions without having to change your business layer logic (Open Closed Principle). The only difference in the way the business logic should interact with the algorithms should be in the constructor, and even there, you should consider using a Factory pattern.