3

I'm really looking more for validation here of my understanding of MVP before I approach the project lead about refactoring major pieces of our application...

We presently have an expanded MVP pattern where we have the following projects:

  • Entity (Defines POCOs)
  • Model (Defines data layer configurations (EF code first - not that it matters here))
  • Task (all business logic in a well ordered grouping)
  • Presenter (page (or page type) specific, calls tasks, defines and works with all View interfaces)
  • View (in the form of different websites (internal, external))

Currently in the View layer I frequently see code that works directly with the Entities, so an ASPX page (could be php, whatever) which has to display a list of entries does so like this:

public interface IEntityList 
{
    ICollection<Entity> MyEntities {get;set;}
    event EventHandler OnReportRunning;
}

public class EntityList : IEntityList
{
    public ICollection<Entity> MyEntities {get;set;}

    private void RenderEntities()
    {
        OnReportRunning(this, null);
        if (MyEntities != null)
        {
            ArrayList entityList= new ArrayList();
            foreach (var entity in Myentities.OrderBy(e=>e.Field))
            {
                var formatedEntity = new {FullName = String.Format("{0}, {1}", 
                    entity.LastName, entity.FirstName), UserEmail = entity.Email};
                entityList.Add(formatedEntity);
            }
            ddlEntities.DataSource = entityList;
            ddlEntities.DataBind();
        }
    }    
}

I'm of the opinion that this violates the intent of the presenter layer. I think the view should expose the DropDownList (ddlEntities) or whatever other controls it has, and the presenter should be the point at which ALL knowledge of the Entity layer stops.

And thus my question - SHOULD the View (V) layer of an MVP (perhaps it should be MPV) architecture have any knowledge of the model (M)? Or am I right in thinking that the only work the View layer should do is direct reactions to events from the controls, and that all real presentation work (binding, formatting involving entities, etc) should be done in the presenter layer, and that the Presenter layer is SUPPOSED to be strongly aware of the actual View layer (IIS vs. Apache vs Mobile etc)?

Marijn
  • 10,367
  • 5
  • 59
  • 80
The Evil Greebo
  • 7,013
  • 3
  • 28
  • 55
  • You simply favor a different flavor of MVP than currently is applied in your project. Denis' answer points this out nicely. Neither one is right or wrong; as long as your team is consistent throughout the application you should be fine. – Marijn Jun 22 '11 at 12:05

1 Answers1

4

What you are suggesting with the "only events" on the view is Passive View flavor of the MVP, I prefer the Supervising Controller, where you do everything except the data binding in the presenter. I usually have something like view.BindData() in which view asks presenter for data and bind it (but of course, the presenter controls when the BindData() will be called, so it ensures that there is some data to bind before the call is made).

I also think that event communication instead of directly calling presenter methods is a overkill in 95% of cases.

Marijn
  • 10,367
  • 5
  • 59
  • 80
Denis Biondic
  • 7,943
  • 5
  • 48
  • 79
  • I think I was somewhat unclear - when I say only events, I mean that the asp page only responds to events from its own controls, and then calls the presenter. That said, what are your thoughts on having the presenter be aware of the end view? Should presenters deal with web controls, or should views be allowed to be aware of the entity layer? – The Evil Greebo Jun 22 '11 at 10:00
  • +1; spot on: OP is favoring the "Passive View" approach to MVP, but in his project "Supervising Controller" is used. Neither one is fundamentally wrong; pick one and stay with it throughout the application. – Marijn Jun 22 '11 at 11:54
  • Note that "passive view" can be implemented with and without events on the view. If you don't use events on the view to which the presenter subscribes, you have to provide the view with a reference to its presenter, [which is perfectly fine IMO](http://stackoverflow.com/questions/6248992/does-presenter-in-model-view-presenter-create-views/6431252#6431252). Works nicely in ASP.NET for instance. – Marijn Jun 22 '11 at 11:59
  • Yes, I believe our designer chose the events model explicitly to avoid having to make the View be aware of the presenter beyond the point of instantiation. This just seems bass ackwards to me - As one ascends (or descends) the hierarchy, the goal is usually to make the current layer unaware of the next, and the next aware of the current. This passive view approach turns that on its head - Entity -> Model -> Task -> Presenter <- View... – The Evil Greebo Jun 22 '11 at 12:08
  • And it occurs to me that this really isn't the right kind of question for SO is it... ;) – The Evil Greebo Jun 22 '11 at 12:09
  • "our designer chose the events model explicitly to avoid having to make the View be aware of the presenter" - maybe this is justified, but beware, there are really rare cases for most apps to do this. On you questions: presenter must be aware of the interface of the view, with real view being injected via presenter constructor. With the view is the same, it depends on the interface of the presenter, not the concrete presenter. – Denis Biondic Jun 23 '11 at 08:18
  • Calling methods on presenter interface from view is perfectly fine - because in the real passive view you have tons of properties exposing control properties and such - which I find cumbersome and not needed. – Denis Biondic Jun 23 '11 at 08:18
  • About the view having only interface of the presenter - I usually have a IView interface where T : IPresenter, so that when creating a view i have: IConcreteView : IView, and IView has a T Presenter {get; set;} - so to tie pieces together it looks something like this: you instantiate presenter which needs concrete view in constructor, and in the constructor you call view.Presenter = this – Denis Biondic Jun 23 '11 at 08:20
  • This is my way of currently doing thing, and from a desktop point of view (WinForms) - for references of the MVP pattern, check ASP.NET MVC how it is done, these patterns all all similar in concepts and have a lot in common – Denis Biondic Jun 23 '11 at 08:22