In MVP, how is Data Model complexity dealt with and where to dynamically show/hide controls?

In most of the MVP examples I've seen, the presenter calls some service, which calls some repository, which returns an entity. In most asp.net web applications that I have worked on, the logic is never that simple. In my last project, my presenter called a presenter service layer that had to jump through hoops to get the data that was to be shown on the screen.

Details: The service layer queries a database for, let's say, 8 entity objects, some of which are nested within each other, then the code maps those entities to one huge object base off of an XSD. That xsd object was then passed to a 3rd party library to do something with it. After it returned the processed xsd obj, the code then had to parse through that xsd object, using a middle layer view formatter class to extract and build what I call the "View Model" (I've heard some call it a DTO). This View model was then returned from the service layer to the presenter and then databound to a repeater.

1. Where does the logic for show/hide controls go? Should that be a member in the DTO or should the presenter derive this value? (I chose to have it as a member in the view model)
2. Is it ok to have nested ViewModels(DTOs) or should other user controls be used to break down the complexity?
3. What is a good way to wire up a presenter with all of the Pages/UserControls that use it; meaning one presenter with 5 IViews that require the same instance of the presenter. Should user controls be self contained or should they rely on the "parent" IView(page) to give it the proper presenter?

4. Instead of having a view model, why not just use the Interface that the Page implements and pass that to the service layer (through the presenter) and let the service hydrate the IView? (Doing this would cause the service layer to have a reference to it, isn't that bad?).

   public class ViewModel
   {
       public bool ShowHeight { get; set; }
       //Is there a bettter way to do开发者_运维知识库 this?
       public List<NestedViewModel> NestedViewModel { get { return _nestedViewModel; } }
   }
   

---

1. IMO, the view should manage itself in showing and hiding; it is the view and is responsible for managing the UI behaviour.
2. I think complexity is OK as long as its not too overbearing; you can break it down into nested subpresenters/views if you need to.
3. Most MVP frameworks populate the presenter/view relationship from the view, especially since ASP.NET runs in the context of the page (the page is the HTTP handler processing the request, so it's what is alive at that point). The page, during init, goes and establishes the view/presenter relationship. Most examples do it this way. I built an MVP framework and have also established this approach.
4. You could; that's considered passive view, though the presenter should still do the work, and not directly pass to the service layer.

This is my opinion and there are many ways to do this.