記事についてのディスカッション

新しいコメント
 

新しい記事「MVCデザインパターンとその可能なアプリケーション」はパブリッシュされました:

本稿では、人気高いMVCパターンと、MQLプログラムでの使用の可能性、長所、短所について説明します。アイデアは、既存コードをモデル、ビュー、コントローラの3つの別々のコンポーネントに分割することです。

このパターンはかなり昔(1978年)に登場しましたが、最初の記述はずっと後の1988年に登場しました。それ以来、テンプレートはさらに発展し、新しいアプローチを生み出しています。

本稿では、複雑さや追加機能のない「クラシックMVC」について考察します。アイデアは、既存コードをモデル、ビュー、コントローラの3つの別々のコンポーネントに分割することです。MVCパターンによれば、これら3つのコンポーネントは独立して開発および保守できます。各コンポーネントは、新しいバージョンの作成とエラーの修正を行う開発者の個別のグループによって開発できます。明らかに、プロジェクト全体の管理がはるかに簡単になり、他の人がコードを理解する手助けともなります。

各コンポーネントを見てみましょう。

  1. ビュー:ビューは、情報の視覚的表現を担当し、一般的なケースでは、ユーザーにデータを送信します。同じデータをユーザーに提示するには、さまざまな方法があります。たとえば、データは、表、グラフ、チャートで同時に表すことができます。つまり、MVCベースのアプリケーションには複数のビューを含めることができます。ビューは、モデル内で何が起こっているかを知らずに、モデルからデータを受け取ります。
  2. モデル:モデルにはデータが含まれています。モデルは、データベースとの接続を管理し、要求を送信し、さまざまなリソースと通信します。また、データを変更して検証し、必要に応じて保存および削除します。モデルは、ビューがどのように機能し、いくつのビューが存在するかについては何も認識していませんが、ビューがデータを要求できるために必要なインターフェイスを備えています。ビューが実行できることは他にありません。つまり、ビューはモデルの状態を強制的に変更することはできず、この役割はコントローラによって実行されます。内部的には、モデルは、階層に配置された、または同等に機能する他のいくつかのモデルで構成できます。モデルは、前述の制限を除いて、この点で制限されていません。その内部構造はビューとコントローラから秘密に保たれます。
  3. コントローラ:コントローラでは、ユーザーとモデル間の通信を実装します。コントローラは、モデルがデータをどのように処理しているかを認識していませんが、コンテンツを更新する時期であることをモデルに通知できます。一般に、コントローラは、モデル内で何が起こっているのかを理解しようとせずに、インターフェイスによってモデルを操作します。

MVCパターンの個々のコンポーネント間の関係は、次のように視覚的に表すことができます。

作者: Andrei Novichkov

 

とても読みやすい記事です！

このテンプレートはテスターにとって理想的だと思います - EAのロジックを変更したり、新しい機能を追加したりするのが簡単です。

例えば、実際の取引で注文をクローズ/オープンする際のエラーなど。

 

このテンプレートはとてもシンプルでわかりやすいからいい。そして、本当に生活が楽になる。一般的に、ツール全体は別々のレンガに分解でき、合理的、論理的に分解できる。そしてコードの再利用、デバッグ、エラー修正、バージョンサポート。

書いているときはエラー処理なんて考えていなかったよ、ありがとう。そして本質的には、エラーが発生したコンポーネントで処理すべきだと思う。例えば、オーダーの設定がViewに参照されるのであれば、そこで処理されるべきだと思います。しかし、それを非同期で行う場合にも問題がある。Controllerのイベントハンドラでは、少し窮屈になります。

ご意見ありがとうございました。）

 
Andrei Novichkov:

そして基本的には、それらが発生したコンポーネントで処理されるべきだと思う。

しかし問題は、エラーが発生し、それ以降のコード（以下にあるコード）を実行しない（abort/またはrollback）ことが要求された場合にどうするかです。

 
例外を説明している )
 
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なのだが、コードの簡素化を口実に、迷路に迷い込んでしまったのだ。結局のところ、MVCはOOPであり、コードの簡素化を口実に、私たちは迷路に迷い込んでしまったのだ：

他人のクラスで、他人のヘッダーファイルで、どうやってグローバルオブジェクトを使うんだ？

最後まで読みましたか？私は最後にコンポーネント間の通信について書きました。そして、グローバル・オブジェクトへのアクセスについても。この場合、大多数の理解を得るために、私は提示された方法を許容範囲と考えます。そして、あなたが提案する方法は、グローバル・オブジェクトへの同じ無制限のアクセスを意味します。

 

MVC、MVP、MVVM hubr: https://habr.com/ru/post/215605/

hubrを信じるなら、この著者の言う通り、MVCではモデルはタスク以外何も知るべきではない（依存すべきではない）。

1234
新しいコメント