記事についてのディスカッション - ページ 2

 
Igor Makanu:

MVC、MVP、MVVMのハブhttps://habr.com/ru/post/215605/

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

もちろん、私はすべてを正しく述べています ))))。しかし、MVCはあまり規律を要求しない。

 

MQLは構造体(コピーコンストラクタ、ファイル操作、SQLite 操作)を扱うことに「長けている」。

MVCテンプレートを使用して、いくつかのステート/パラメーター構造を通してインタラクションを構成することは現実的でしょうか。それとも別のテンプレートが必要でしょうか?

 

とても現実的だ。いい方法だこの方向での発言は前述した。しかし、ある構造体への参照ではなく、コンポーネントそのものへの参照を交換する方がよい。例えば、ビューはモデルにアクセスする必要があるかもしれない。ただ、ビューがモデルを変更してはならないことを覚えておいてください。したがって、アクセスは適切でなければなりません。

 
Andrei Novichkov:
とても現実的だ。いい方向だ。上のコメントは、まさにその方向でなされたものだ。

例が必要

あるいはもっと良い記事が...。ただ、サーバーのエラー処理は できる

 
Igor Makanu:

あるいは、もっといい記事を......。サーバーのエラー処理

まあ、原理的にはできる。)番目の部分は、原始的なレベルではなく、実際に動くレベルにしてください。考えてみます。同じ場所で記事を作りたくない。

 
Andrei Novichkov:

第2パートは原始的なレベルではなく、現実的で実用的なレベルにする。

それが誰にとっても実用的だと思います。

そして、エラー処理について記事を100と50のセクションに膨らませないために、1-2個のサーバーエラー(注文の送信/クローズ)と1-2個のターミナルエラー(現在の価格/タイムフレームの取得?......)を処理できれば十分だと思います。

エラーもEAの状態の保存も、構造体を使って効率的にバイナリファイルにまとめることができるのではないだろうか。

 
Andrei Novichkov:

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

あなたは、私がすでに記事の中であなたの言い訳に言及していることに気づいていないようだ。

あなたはほとんどの人に、MVCやOOPではなく、どのようにやってはいけないかを教えている。そして、緑で強調されたフレーズは、それがどのように実装されるべきかについてのあなたの間違った理解を反映しているに過ぎない。

 
Stanislav Korotky:

どうやらあなたは、私がコメントですでに言及していたのが、記事の中のあなたの言い訳だったことに気づいていないようだ。

あなたは、MVCやOOPではなく、どのようにやってはいけないかを大多数に教えている。そして、緑で強調されたフレーズは、それがどのように実装されるべきかについてのあなたの間違った理解を反映しているだけだ。

それは私の理解ではない。そして、私が正しいと思っているのは、学習プロセスについての私の理解だ。
 

本当にこの記事のコメントで議論する価値のあることなのか?

私たちのフォーラムは、どれだけこの種の表現/アドバイスが好きなのか、私は驚いています ))))。ちなみに、私はあの辺りで勤務していました、中国まで歩いて半日でした )))

 
Andrei Novichkov:
本当にこの記事のコメントで議論する価値があるのですか?

次の記事で修正してください。