1

私が現在行っているいくつかの作品のデザインについて、あなたの考えを教えていただけないでしょうか。

現在の状況は次のとおりです-基本的に：

  • アプリケーション用の一連のコントロールを開発しています。
  • これらの一部は、WinForms と ASP.NET Web アプリケーションの両方で使用できます。
  • 私は自分のコードのテストとテスト容易性を改善するために絶え間ない努力をしています。

だから、ここに私がしたことがあります：

  • UI の概念を持たないクラスでコア コントロール ロジックを作成しました。物事が変化したときにイベントを発生させるだけです。すべてのデータは、他のものと区別する必要があるカスタム型付きオブジェクトとして保存されます (たとえば、あるPagingControl場所SelectedPageとPageNumberアイテムがあります)。
  • 次に、レンダリング「エンジン」のインターフェースとして機能する抽象クラスを作成しました。これにより、コア ロジックに使用される (場合によっては追加される) カスタム タイプがエンジンによって確実に処理されます。上記の例に続いて、抽象メソッドが含まれていますRenderSelectedPage。
  • 次に、抽象レンダリング エンジンの具体的な実装を作成しました (例:ConsoleRenderingEngineなどHtmlRenderingEngine)。これにより、メソッドが処理され、必要に応じてそれぞれの UI/出力にレンダリングされました。

このアプローチには、次の長所と短所があります。

プロの

  • できます。新しいレンダリング メカニズムを実装するのは非常に簡単です。抽象エンジンをサブクラス化し、出力をレンダリングするだけです (必要な参照が渡されます)。
  • UI がコア コードから分離されているため、テストがはるかに簡単になります。

  • 明らかに、コア/レンダリング ロジックがカプセル化されているため、問題が発生したときにどこに問題があるかが明確になります。

    短所

  • 紛らわしい/肥大化したように見える場合があります。各クラスには大量のコードはありませんが、1 つの出力 (1x コア、1x インターフェイス、1x レンダラー) にレンダリングするための 3x クラスがあります。ただし、WinForms/WebForms コントロールを作成する場合は、別のクラスも意味します (Controlと同様にサブクラス化する必要があるためAbstractRenderingEngine)。

... OK、それが私が本当に考えることができる唯一の「詐欺」であり、この質問の主な理由です ^_^

そう、

この「パターン」についてどう思いますか？どのように変更/改善しますか?

この質問は、より多くの考えが浮かぶと更新されるか、明確さが求められる場合があります (私はそれが重い読み物であることを知っています!)。

アップデート

答えてくれてありがとう、あなたがMVPと言ったのはおかしいです、私はこのようなものをどこかで見たと思っていましたが、それが何であったかを一生思い出せませんでした! 「MVP」を見た瞬間、「くそっ」と思いました。:D

返信ありがとうございます。MVP をもっと勉強して、自分が持っているものをさらに改善できるかどうかを確認します。

4

1 に答える 1

2

あなたの説明から、それは私が MVP を行う方法に少し似ていますが、イベントは逆になります。

私は通常、インターフェイスの後ろに隠れていて、プレゼンターについて何も知らない非常に薄いビューを持っています。ビューは、ユーザー アクションでイベントをスローするビューです。通常、ビューはプリミティブに固有の UI を変換するか、場合によってはモデルの値オブジェクト (.net 構造体ではなく、ddd の意味での値オブジェクト) を変換します。より複雑な状況や再利用のためにビューをネストすることもあります。UserControls には、独自のビューとプレゼンター構造がある場合があります。ビューのネストとプレゼンターのインスタンス化を開始すると、オブジェクトのインスタンス化に多くの作業が必要になるため、通常、IoC コンテナーを探し始めるのはこのときです。

プレゼンターは、そのインターフェイスを介してビューを認識し、直接話しかけます。ビュー イベントに反応し、ほとんどのロジックを実行します。ビューとモデルはプレゼンターに Di'd されるため、その中のすべてのロジックをテストできます。

私が見た別のアプローチは、ビューがプレゼンターについて知っていて、プレゼンターがインターフェイスを介してのみビューについて知っていたというものでした。これにより、ビューがプレゼンターと直接対話できるため、ビュー アクションのイベントを発生させる必要がなくなります。(これは smalltalk の世界で MVC と呼ばれていたものだと思います) プレゼンターはまだテスト可能であり、これにより、ビューからプレゼンターへのデータバインディングを行うことができます。私は通常データバインディングを使用しないので、これは大きな利点ではありません。最初の例のように、もう少し分離します。

于 2008-09-22T13:08:24.357 に答える