私たちは、Model-View-Presenter パターンを (事実上) すべての新しい開発作業で使用しようとしています。
私は人々が設計要件を満たすのに役立つフレームワークを持つことを強く信じています。さまざまなコンポーネント (ロギング、電子メール送信など) 用の社内フレームワークがいくつかあるので、ある種の MVP を取得しようとしています。フレームワークを開発しました。
MVP に慣れていない人にも使いやすく、現在の作業方法からそれほど離れていないものをまとめることができました。問題は、1 ビューと 1 プレゼンターの関係を行っていることです。
フレームワークの大まかな概要は次のとおりです。
public abstract class Presenter<TView> where TView : IView {
public virtual T View { get; set; }
public virtual void Setup(TView view) {
this.View = view;
}
}
public interface IView { }
それが機能する基本的な方法は、作成されたビューIViewがインターフェイスから継承され、抽象クラスから継承されたプレゼンタークラスに渡されることです。Presenter
ご覧のとおり、私は .NET ジェネリックを使用しているため、開発者はプレゼンター (そして最終的にはプレゼンターから継承するクラス) で作業しているときにビューの厳密な型指定を行うことができます。
したがって、次のような基本的なログイン コンポーネントを設定できます。
public class Login : Presenter<ILogin> {
public override Setup(ILogin view){
base.Setup(view);
this.View.Login += new EventHandler(login);
}
void login(object sender, EventArgs e) { ... }
}
public interface ILogin : IView {
string Username { get; set; }
string Password { get; set; }
event EventHandler Login;
}
私がこれをとても気に入っていると述べたように、コンパイラ強制型付け、強く型付けされたビュー、および MVPのようなパターンがあります。
ただし、プレゼンターとビューの間に 1 対 1 の関係があるため、実装にそれほど満足していない人もいます。厳密に言えば、これは MVP の本来のあり方ではありません。
この議論が実際にどれほど有効であるか疑問に思います.このフレームワークを追跡してきたいくつかのプロジェクト(中規模から大規模のプロジェクトまで)で、「このプレゼンターには複数のビューが必要だ」と考えた良い例は見つかりませんでした. . 複数のビューで共有できる機能を見ると、特定のプレゼンターに関連付けるべきなのか、それともより中立的なクラスにすべきなのか疑問に思います。
私が達成しようとしているフレームワークは、MVP と呼ばれるには MVP から遠すぎますか? プレゼンターに複数のビューを提供する必要性は、MVP の主な目標ですか? n ビューをサポートする真の .NET MVP フレームワークを持つことさえ可能ですか?