Features | Tutorial | Documentation | Downloads | Links | F.A.Q. | Glossary | Current Release

Presenter Hierarchy for Version 1.0.0 Vision Statement


We are evaluating several options, but so far using a plugin structure allied to the Decorator Design Pattern seems to be a better choice than implementing a new hierarchy of presenters.

Plugin Structure + Decorator Design Pattern (Through attributes)


  1. More flexibility, since the developer can choose exactly which features to increment his presenter with.
  2. Easily add new features to the presenter structure without breaking existing codebase.
  3. Partial Compile-time support, via a GetPlugin<PluginType> method that returns a typed instance from the Presenter class.
  4. Community Support for creating new presenter functionality. Just create a new presenter plug-in, decorate your presenter with it and it's working.


  1. Partial compile-time support. Methods used by each attribute aren't just overrides, so they have to be convention-named (i.e. Validate()).
  2. Can be somewhat misleading if users start to place business logic into plug-ins.

Sample Code (just to illustrate)

  [LogEnabledPresenter(LogLevel.Verbose, LogDestination.EventLog)
  public class CustomerDetailsPresenter : Presenter<ICustomerDetails>{
    //regular presenter implementation...

    public void Save(){
      GetPlugin<LogEnabledPresenter>().Log("Saving Customer Details...");
      //Save logic in here...

    public bool Validate(){
      //Validation logic in here...

    private SecurityContext securityContext;
    //This property would be automatically filled by the NMVP engine.
    public SecurityContext SecurityContext{
      get { return securityContext; }
      set { securityContext = value; }

As it's clear from the code above, the methods have their names via convention, and thus if you spell then wrong or anything (different parameters, different access) you won't notice it until runtime, which is really not good. Note that the actual decoration involved with the pattern (composing presenters) would be performed by the NMVP Engine, so no trouble there.

New Hierarchy


  1. Compile-time support, so when the users need to know what methods they can override it's easier.


  1. Can be misleading as well if users don't want to use all methods that a given level of the hierarchy offers.
  2. Very hard to build a hierarchy that covers all combinations, and each time a new feature is included, this becomes even harder (N*N-1).

Sample Code (just to illustrate)

  public class CustomerDetailsPresenter 
                           : ValidatingPersistentSecurePresenter<ICustomerDetails> { 
                            //See how hard it is?
    //regular presenter implementation...

   protected override void SaveCore(){
      //Save logic in here...  This method will get called when the user 
      //of this presenter calls Save. This is how it's done today.

    protected override bool ValidateCore(){
      //Validation logic in here... This method will get called when the user 
      //of this presenter calls Validate. This is how it's done today.

Plugin Infrastructure

We are hoping to achieve a community-based plugin repository for NMVP. Since the presenter is the dorsal spine for anyone using the MVP pattern, we would like to spend most of our efforts in it. If there's one single point to improve in NMVP, it's the presenter infra-structure.

So we came up with the idea of using plug-ins for the presenter. The plug-ins would be built by implementing IPlugin or inheriting from PluginBase.
The IPlugin interface would have some properties filled by the NMVP Engine, once the presenter is created. One of those properties would be the presenter itself, in a way that allows the Plugin to participate in the presenter life-cycle.

So what one would need to do to create a new plugin and use it:
  1. Develop a plugin with some defined functionality that implements IPlugin (and inherits from Attribute of course) or inherits from PluginBase
  2. Decorate a presenter with the given Plug-in.
Seems pretty simple to us, and hopefully will allow for greater extensibility options. The major point here is reducing the entry barrier for plug-in development, so we can see some response from the community sooner. We really expect to create a plug-in repository so that the community can help itself.

Last edited Aug 18, 2007 at 3:10 AM by Heynemann, version 4


No comments yet.