views:

46

answers:

2

I have traditionally implemented a Model-View-Presenter [Passive View] like so:

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";
}
...
}

and I have traditionally only used primitive types in the IView interface (int, string, bool) because I have always understood that you need to use primitive types only in the View. In a Repository (such as NHibernate), if I want to display a list of items in a DataGridView, I have to pass a generic collection (IList<T>) from the Model to the Presenter. Does that violate the rule behind views as consisting only of primitive types or would this architecturally be OK?

Even if I had a Data Transfer Object (DTO), that would be more of a supervising controller rather than passive view style I am trying to implement.

Thoughts??

+1  A: 

Wow maybe I've been missing out on a lot. I've never seen views as being limited to only displaying primitive types.

I'd be interested to know why this restriction is used and what the benefit of it is? That's not to say that "IMO it's totally wrong", but I'm curious as to its benefits. My belief is that computers are sufficiently powerful now that unless you are targetting a specific performance specification the cost of a developer hammering away to fit some guideline would be an expensive use of resources.

Not that it's any endorsement per se. but all the MVC articles I've seen have been happily banding around classes between the view and controller. Since MVP is just a different form of MVC I'd say if it's not a problem with MVC should it be with MVP?

Dylan
Well I could easily pass an IList from the Model to the Presenter to the View to be displayed by a DataGridView and nothing technically prevents it, but not sure if that is architecturally the right answer or should I use some other lightweight means.
0A0D
+1  A: 

Patterns exist to help you design your solution based on others' experiences.

They are nothing more than formalized templates.

Use whatever structure makes you more productive, even if it doesn't fit an arbitrary definition perfectly.

Diego Mijelshon