3

優れた MVC 実装のリトマス試験紙は、ビューの交換がいかに簡単かということです。私は怠け者だったので、いつもこれを本当に下手にやっていましたが、今は正しくやりたいと思っています. これは C++ で書かれていますが、誇大宣伝を信じるなら、デスクトップ以外のアプリケーションにも同様に当てはまるはずです。

以下に 1 つの例を示します。アプリケーション コントローラーは、バックグラウンドで URL が存在するかどうかを確認する必要があります。次のように、(Boost シグナルを使用して) "URL available" イベントに接続できます。

BackgroundUrlCheckerThread(Controller & controller)
{
   // ...
   signalUrlAvailable.connect(
      boost::bind(&Controller::urlAvailable,&controller,_1))
}

それで、どのようにController::urlAvailable見えますか？

1 つの可能性を次に示します。

void
Controller::urlAvailable(Url url)
{
    if(!view->askUser("URL available, wanna download it?"))
      return;
    else
      // Download the url in a new thread, repeat
}

これは、私には、ビューとコントローラーの全体的な結合のように思えます。このような結合により、Web を使用するときにビューを実装することができなくなります (コルーチンは別として)。

別の可能性:

void
Controller::urlAvailable(Url url)
{
   urlAvailableSignal(url); // Now, any view interested can do what it wants
}

私は後者に部分的ですが、これを行うと次のようになります。

  1. 400億のそのような信号。アプリケーション コントローラは、自明でないアプリケーションでは巨大になる可能性があります
  2. 特定のビューが誤っていくつかのシグナルを無視する非常に現実的な可能性 (API はリンク時に通知できますが、シグナル/スロットは実行時です)

では、カップリングを取り除き、複雑さを抑えるために何を提案しますか? 前もって感謝します。

4

2 に答える 2

4
于 2010-04-07T02:35:31.177 に答える
0

「m」モデルを使用してそれらを分離し続け、(概念上) コマンドに似たパターンとリスナー パターンを使用して、複雑さを抑えます。

したがって、コントローラーは次のようになります。

void
Controller::urlAvailable(Url url)
{
   Controller::fireSignal("urlAvailable", url, ... other possible parameter);
}
Controller::fireSignal(char* cmd, Url url, ... other possible parameters) {
   Model &M   = new Model();
   M->command = cmd;
   M->url     = url;
   M-> ... other possible
   for(int v = Controller::ViewCount; --v >= 0; )
      Controller::Views[v]->notice(M);
}

注: 私は C++ プログラマーではないので、間違った文法についてはご容赦ください。

MVC の全体的な考え方は、M(odel) を使用して C(ontrol) を V(iew) から分離することです。この例は非常に単純化されています。より実用的な方法は、異なる種類の類似信号に対して異なるモデルを使用することです。

お役に立てれば。

于 2010-04-07T02:00:06.103 に答える