文章 "MVC 设计范式及其可能的应用"

新评论
 

新文章 MVC 设计范式及其可能的应用已发布：

本文讨论了一种流行的 MVC 范式，以及它运用在 MQL 程序中的可能性、优缺点。 这个思路是将现有代码拆分为三个独立的组件：模型、视图和控制器。

在本文中，我们将研究“经典 MVC”，没有任何复杂性或附加功能。 这个思路是将现有代码拆分为三个独立的组件：模型、视图和控制器。 根据 MVC 范式，这三个组件可以独立开发和维护。 每个组件都可由单独的开发团队开发，他们承担创建新版本，并修复错误。 显然，这可令整个项目的管理更加容易。 甚而，它能够帮助其他人理解代码。

我们来看看每个组件。

  1. 视图。 视图负责信息的可视化呈现。 在一般情况下，它向用户发送数据。 向用户呈现相同的数据，可以有不同的方式。 例如，数据可以同时用表格、图形或图表来呈现。 换言之，一个基于 MVC 的应用程序可以包含多种视图。 视图从模型接收数据，无需知道模型内部发生了什么。
  2. 模型。 模型包含数据。 它管理与数据库的连接、发送请求、并在不同的资源间进行通信。 如有必要，它会修改数据、验证数据、存储和删除数据。 模型无需知道视图如何操作，以及存在多少视图，但它拥有必要接口，能响应视图请求数据。 视图不能做任何强迫模型更改其状态的事情。 这部分是由控制器来执行。 在内部，一个模型可由若干其他模型组成，它们或按层次结构、或按等同操作来排列。 除了前面提到的限制之外，模型在这方面没有极限 — 模型的内部结构相对于视图和控制器始终保密。
  3. 控制器。 控制器实现用户和模型之间的通信。 控制器不知道模型如何处理数据，但它可以告诉模型更新内容的时间。 通常，控制器通过其接口操控模型，不必尝试了解其内部发生的事情。

MVC 范式的独立组件之间的关系可直观地表示如下：

作者：Andrei Novichkov

 

文章写得很好，很容易读懂，谢谢！

我认为这个模板非常适合测试人员--很容易更改 EA 逻辑并添加新功能。

关于 MVC，您建议如何处理错误？

 

模板很好，因为它非常简单清晰。我亲身经历过，它确实让生活变得更轻松。总的来说，整个工具可以分解成独立的砖块，并且分解得合理、合乎逻辑。你可以获得代码重用、调试、错误修复和版本支持。

我在写的时候没想过错误处理，谢谢。从本质上讲，我认为应该在发生错误的组件中进行处理。也就是说，如果订单设置被引用到了视图，那么就应该在视图中进行处理。但如果以异步方式进行，也会出现问题。控制器中的事件处理程序会显得有些拥挤。

感谢您的宝贵意见 )

 
Andrei Novichkov:

从根本上说，我认为这些问题应该在它们产生的地方得到处理。

每个人都会这样做，这是合乎逻辑的--但问题是，如果出现错误，并且要求不执行（中止/或回滚）代码（代码在下面），该怎么办？

 
您描述的是一个例外 )
 
Andrei Novichkov:
你说的是例外情况）。

什么异常？- 它们在 MQL 中并不存在，也许某个开发人员写道：这是一种糟糕的程序编写 方式，没有必要......嗯，这并不准确！))))


SZY：我认为，对于测试人员来说，你应该用 MVC 来编写程序，而对于真正的测试人员来说，你应该将一部分关键部分的代码移到 OnTimer() 和...同样，我们将得到的不是使用普通编程模板（方法）的简单可读代码，而是.....可能是一个 MQL 风格的程序 ))))

 

这个例子并不是很好，事实上，视图是在 EA 之外的。

更夸张的是，您不应该在交易函数 中保留模型的逻辑。如果错误影响了逻辑--函数会抛出一个事件，控制器会处理该事件，模型会决定下一步该做什么。

 
MVC 并不是一个僵化的模板，允许出现偏差。当然，也有 "纯净冠军"，但这应被视为一种自然现象
 

原则上，这很糟糕。他们宣布了一种有用的模式，但却展示了如何不这样做：毕竟，MVC 是 OOP，而在这里，在所谓简化代码的借口下，我们得到了一些迷宫。至少他们可以把 init（又称控制器）扔进模型和视图中：

int OnInit()
{
   init.Initialize(smb);
   view.Initialize(&init);
   // model.Initialize(&init);
  
   return INIT_SUCCEEDED;
}
全局对象怎么能用在别人的类里、别人的头文件里？
 
Stanislav Korotky:

原则上，这很糟糕。他们宣布了一种有用的模式，但却展示了如何不这样做：毕竟，MVC 就是 OOP，而在这里，以所谓的代码简化为借口，我们得到了一些迷宫。至少他们把 init（又名控制器）扔进了模型和视图中：

你怎么能在别人的类里、在别人的头文件里使用全局对象？

你读完了吗？我在最后写的是组件之间的通信。还有对全局对象的访问。在这种情况下，我认为提出的方法是可以接受的，只是为了让大多数人理解。而你建议的方法意味着同样不受控制地访问全局对象，只是从侧面而已。

 

原来要复杂得多 - MVC , MVP , MVVM hubr: https://habr.com/ru/post/215605/

如果你相信 hubr，那么作者说得没错，在 MVC 中，除了任务之外，模型不应该知道（依赖）任何东西。

1234
新评论