Proper implementation of MVP with complex controls

I'm currently implementing a project using asp.net, c# and the MVP (Model-View-Presenter) pattern. The main purpose of this solution is to deliver a graph to the consumer, to be used by a variety of systems. It is basically a custom graph server.

The view page in this particular case has an MSChart control on it, which has to be dynamically populated and configured based on parameters in the QueryString. This can be as diverse as totally different types of data sets, display modes and so on, using a lot of the properties of the chart control.

Many of these properties are again of types which are particular to the chart control and would require the same dependencies as the chart control itself if they are to 开发者_运维技巧be set by the presenter.

I'm trying to figure out the best way to expose the properties to the presenter so it can work its magic.

Should I:

• Just expose the whole chart object and live with a system.web type dependency in the presenter project?
• Make accessor and translation properties for all of the chart control properties so that I don't have the dependency, but add lots of complexity?
• Other, that I haven't thought of?

To me it seems that it would be against the MVP pattern to bubble a display control up into the presenter, but it seems that trying to map all the properties to DTOs or similar would be a lot of work that would add a lot of complexity, and while the solution would be somewhat more loosely coupled, I'm not sure the gain would be worth it in this case.

How would you implement something like this, given MVP?

While doing some more research on this topic, I found the following blog post on adding a Presenter Model to handle complex view controls, to map between the view and the presenter. It actually made a lot of sense to me, and it's an idea I think I'm going to follow up on and try.

http://mikewagg.blogspot.com/2009/01/managing-complexity-with-mvp-and.html

In fact, Martin Fowler has written on this as well:

http://martinfowler.com/eaaDev/PresentationModel.html

Check out Automapper. Makes translating from a Business Object to a View Model almost effortless. The general idea is your View Model should only have primitive system types if possible to avoid formatting/conditionals in your view.