MVP パターンの記事に書くかもなこと

チラシの裏 MVC

考え途中なので当てにしないでね＞＜

  • 大きな選択肢
    • Presenter のライフサイクル
      • ポストバックの度に Page.PreInit で生成
        • セッションに入れないのでタイムアウトとか無い
        • Application レイヤにビジネスファサードを用意し、これをセッションに入れればセッション管理も単純にできる
      • 非ポストバック時に生成しセッションに格納
        • セッションに入れるのでタイムアウトとかある
        • Application レイヤがなくともセッション管理は単純
    • View インターフェイスの粒度
      • UI コントロールのプロパティレベルを操作
        • 例 : string titleTextBox_Text { set; }
        • より多くのプレゼンテーションロジックをテストできる
        • Presenter の実装やインターフェイスは結構複雑になる
        • データバインドは不向き
        • View は Model を (ほぼ) 意識しない
        • 複数データを扱う場合は Table を使って TableRow を動的生成 (データバインドではインターフェイスの粒度が粗くなる)
          • TableRow を継承 (あと Presenter から扱えるようにインターフェイスも) し、タイプセーフに扱う。
            • 例 : class BookTableRow : TableRow, IBookTableRow
          • 動的生成は必ず Page.Init で行う
      • Model をやりとり
        • 例 : void SetBook(Book target);
        • テスト対象から外れるプレゼンテーションロジックが多くなる
        • Presenter の実装やインターフェイスは結構綺麗になる
  • 一機能で複数画面があるとき
    • Presenter を毎回生成する場合、ビジネスファサードの受け渡しとかの管理が複雑になる
    • Presenter をセッションに入れる場合、Presenter のライフサイクルの管理が複雑になる
    • 対策
      • 一機能につき一つの aspx にし、ascx (+ MultiView) で擬似的に複数画面を表現
        • IsPostBack が false の場合だけセッションに格納すれば良い
        • FunctionalPresenter を用意しておき、これを継承すると良い
        • デザイン側がちょっと複雑になる
          • ユーザーコントロールにコンテンツを記述するので、マスターページで複数の ContentPlaceHolder を用意することができない
          • デザイン時に、ユーザーコントロールに CSS を反映させるのは難しい
      • 各機能毎にゲートとなるページ (ex:Gate.aspx) を用意
        • ゲートでセッションに格納して本来の開始ページにリダイレクトすれば良い
        • GatePresenter と FunctionalPresenter を用意しておき、これを継承すると良い
        • Presenter を毎回生成しビジネスファサードをセッションに格納する場合のみ可
  • 毎回生成の場合の Page とか Presenter の 継承
    • Presenter と GatePresenter と FunctionalPresenter を用意しとくと良い
    • IView を用意しとくと良い
    • MvpPage クラス を用意しとくと良い (IView も実装)