Model-View-Presenterおよび大きなオブジェクトの転送

Question

私は伝統的にモデルビュープレゼンテル[パッシブビュー]を実装してきました。

interface IView
{
string Title {set;}
}

class frmTextBox : Form, IView
{
...
public string Title
{
set { this.txtTitle.Text = value; }
}
...
}


class frmLabel : Form, IView
{
...
public string Title
{
set { this.lblTitle.Text = value; }
}
...
}

class Presenter
{
private IView view;
...
public void UpdateTitle
{
this.view.Title = "A Good Title";
}
...
}

そして、私は伝統的にプリミティブタイプしか使用していませんでした IView インターフェース （int, string, bool）私はあなたがビューでのみプリミティブタイプを使用する必要があることを常に理解していたからです。リポジトリ（ NHibernate）、にアイテムのリストを表示したい場合 DataGridView, 、私は一般的なコレクションを渡さなければなりません（IList<T>）モデルからプレゼンターへ。それは、原始的なタイプのみで構成される見解の背後にあるルールに違反していますか、それともこれは建築的に大丈夫でしょうか？

データ転送オブジェクト（DTO）があったとしても、それは私が実装しようとしているパッシブビュースタイルではなく、より監督するコントローラーのようなものになります。

考え？

Answer 1

他の人の経験に基づいてソリューションを設計するのに役立つパターンが存在します。

それらは正式なテンプレートにすぎません。

任意の定義に完全に適合しなくても、どんな構造を使用しても、生産性を高めます。

Answer 2

うわー多分私はたくさん見逃してきました。私は、原始的なタイプのみを表示することに限定されていると見なしたことがありません。

なぜこの制限が使用されているのか、そしてそれの利点が何であるかを知りたいと思います。それは「IMOは完全に間違っている」と言っているわけではありませんが、その利点については興味があります。私の信念は、特定のパフォーマンス仕様をターゲットにしていない限り、コンピューターはいくつかのガイドラインに適合するためにハンマーを追い払うコストがリソースの高価な使用になると、コンピューターは十分に強力であるということです。

それ自体が承認されているわけではありません。しかし、私が見たすべてのMVCの記事は、ビューとコントローラーの間のクラスの周りに喜んで縛られています。 MVPはMVCの別の形式であるため、MVCに問題がない場合はMVPに問題がなければなりませんか？