6

コードでCockburnのユースケースを試す

複雑な UI コードを書いていました。私は、魚、凧、および海面 (Martin Fowler の著書「UML Distilled」で説明) を使用した Cockburn の使用例を採用することにしました。UI ワークフローのステップを表す静的定数に対して論理条件をテストできるように、Cockburn のユース ケースを静的 C# オブジェクトでラップしました。ラップされたオブジェクトとそのパブリック コンタントが名前空間を介して英語のユース ケースを提供するため、コードを読んで、それが何をしているかを知ることができるという考えでした。

また、リフレクションを使用して、説明したユース ケースを含むエラー メッセージを送り出すつもりでした。アイデアは、スタック トレースにいくつかの UI ユース ケースの手順を英語で含めることができるということです....DSL コンパイラを作成する必要なく、ミニで疑似軽量のドメイン言語を実現する楽しい方法であることが判明しました。だから私の質問は、これがこれを行う良い方法であるかどうかです? 誰かが同じようなことをしたことがありますか？

c# の例のスニペットが続きます

3 つのユーザー コントロール (多数のクリック可能な要素) を持つ aspx ページがあるとします。ユーザーは 1 つの特定のユーザー コントロール内のものをクリックする必要があり (おそらく何らかの選択を行う)、UI は選択が成功したことをユーザーに視覚的に知らせる必要があります。ここで、その項目が選択されている間、ユーザーはグリッドビューを参照して他のユーザー コントロールのいずれかで項目を見つけ、何かを選択する必要があります。これは簡単に管理できるように思えますが、コードが見苦しくなります。

私の場合、ユーザーは、メイン ページによってキャプチャされたすべての送信済みイベント メッセージを制御します。このようにして、ページは UI イベントの中央プロセッサのように機能し、ユーザーがクリックしたときに何が起こるかを追跡できました。

そのため、メインの aspx ページで、最初のユーザー コントロールのイベントをキャプチャします。

using MyCompany.MyApp.Web.UseCases;   

protected void MyFirstUserControl_SomeUIWorkflowRequestCommingIn(object sender, EventArgs e)
{
  // some code here to respond and make "state" changes or whatever
  //
  // blah blah blah


  // finally we have this (how did we know to call fish level method?? because we knew when we wrote the code to send the event in the user control)
  UpdateUserInterfaceOnFishLevelUseCaseGoalSuccess(FishLevel.SomeNamedUIWorkflow.SelectedItemForPurchase)

}



protected void UpdateUserInterfaceOnFishLevelGoalSuccess(FishLevel.SomeNamedUIWorkflow  goal)
{
  switch (goal)
  {
     case FishLevel.SomeNamedUIWorkflow.NewMasterItemSelected:
           //call some UI related methods here including methods for the other user controls if necessary....
           break;
     case FishLevel.SomeNamedUIWorkFlow.DrillDownOnDetails:
           //call some UI related methods here including methods for the other user controls if necessary....
           break;
     case FishLevel.SomeNamedUIWorkFlow.CancelMultiSelect:
           //call some UI related methods here including methods for the other user controls if necessary....
           break;

     // more cases...


     }
  }

}


//also we have
protected void UpdateUserInterfaceOnSeaLevelGoalSuccess(SeaLevel.SomeNamedUIWorkflow  goal)
{
  switch (goal)
  {
     case SeaLevel.CheckOutWorkflow.ChangedCreditCard:
        // do stuff


     // more cases...


     }
  }

}

したがって、MyCompany.MyApp.Web.UseCases 名前空間には、次のようなコードが含まれている可能性があります。

class SeaLevel...
class FishLevel...
class KiteLevel...

クラスに埋め込まれたワークフローのユース ケースは、内部クラス、静的メソッド、列挙型など、最もクリーンな名前空間を提供するものであれば何でもかまいません。最初に何をしたか覚えていませんが、写真はわかります。

4

2 に答える 2

2

私はそれをやったことがありませんが、UC スタイルでコードを書くことをよく考えました。主な成功パスを最初に置き、拡張機能を例外として下に置きます。それを行う言い訳が見つかりませんでした - 誰かがそれを試してコーディングするのを見てみたい.

于 2010-06-07T00:07:26.827 に答える
1

これは、 Design Patterns (Gang of Four)の Mediator パターンのバリエーションだと思います。つまり、これは有効な方法だと思います。パターンでは、コントロール間の複雑な相互作用がそれを使用する理由であると議論しています。

編集：ウィキペディアのメディエーターへのリンク

于 2008-09-23T12:03:28.577 に答える