Puzzled in MVP patterns

Aug 19, 2009 at 11:12 AM

Hi, Admin,

These days I transfer SL project into Prism, now I have a question about MVP patterns.

Each time I click the button, the view will add 2 textblock. So there are 2 ways to do that.

1.Directly write code behind, I still use Command, but without MVP patterns:

        <StackPanel Orientation="Horizontal"   HorizontalAlignment="Left" x:Name="StationPanel">
            <TextBox x:Name="Station1" Text="YAP" Width="45" Margin="40,4,4,4" />
            <TextBox x:Name="Station2" Text="ROR" Width="45" Margin="4,4,4,4"/>

            <Button x:Name="btnAddStation" Content="Add..." cmd:Click.Command="{Binding AddStationCommand}" Width="40" Height="24"  Margin="4,0,4,0" />
	public DelegateCommand<Object> AddStationCommand = new DelegateCommand<Object>(OnAddStationCommandExecute);
        void OnAddStationCommandExecute(Object obj)
            StackPanel sp = new StackPanel { HorizontalAlignment = HorizontalAlignment.Left, Orientation = Orientation.Horizontal };
            sp.Children.Add(new TextBox { Width = 45, Margin = new Thickness(40, 4, 4, 4) });
            sp.Children.Add(new TextBox { Width = 45, Margin = new Thickness(4, 4, 4, 4) });

2.Binding StackPanel to the Model, implement INotifyPropertyChanged and use ObservableCollection, and define a ControlTemplate.The code is too complex to list here.
Which method is preferred? 
I think 1st is beetter. As you know, Winform, WPF and ASP.NET is a Mediator pattern(GOF23) before we introduce Prism, so form manage the relation between all the controls regisit in it. It is easy to understand, especially only change interface rather than modify any data behind.
Why do we need to write MVP for MVP? 
Aug 19, 2009 at 4:06 PM

I think there are several reasons for separating the code from the view in some for MVVM / MVP:

  • It is impossible for you to use tools to style your output in any way with the code behind that way.
  • It is difficult to perform good unit tests on your code without the patterns but this is only a concern if you are writing unit tests.
  • Patterns make it easier for developers to understand how to implement something and less likely for them to deviate the code (maintenance). There are many ways to achieve the same thing in software development and unless you specify how people are to implement things, the code maintenance down the road becomes problematic or even sooner on larger projects and teams.

With a little effort, you can move much of your common implementations into the infrastructure so #2 becomes less code and more business solution. My base ViewModel implements the INotifyPropertyChanged interface and I have created snippets to create many of my common structures so it becomes quick to get what I need implemented.

In the end, it will really depend on your teams experience level and what they can tolerate from development and learning. If the team is relatively junior, then keeping the code at a level they know and understand is probably the best approach.

Aug 19, 2009 at 5:59 PM


As fredhirschfeld said, the recommended approach in the scenario can vary based on your application requirements. My personal recommendation would be the following:

  1. If, as it seems the case, you add the Textblocks simply for UI update purposes (no other business logic required), I would place the code in the View’s code behind. This is because it is an UI operation.
  2. If you add the Textblocks as some part of the business logic requirements, then I would place the code in the ViewModel/Presenter, create a command in the ViewModel to execute when the button is clicked and perform the necessary logic there.

Please let me know if this helps.

Damian Schenkelman

Aug 20, 2009 at 5:07 AM

Hi, my friend, fredhirschfeld and dschenkelman,

Thanks for your valuable feedback.

As dschenkelman said,

"If you add the Textblocks as some part of the business logic requirements, then I would place the code in the ViewModel/Presenter, create a command in the ViewModel to execute when the button is clicked and perform the necessary logic there."

I agree, but if the button click event involve some business logic and some UI update, how about the implementation?

I think MVP is easy to do it, because Presenter have a reference to the IView, Presenter can invoke IView's method to do UI update, and do business logic in service layer.

But in VM, because the standard implementation is View have a reference to the ViewModel, but ViewModel doesnot have a reference to the View. So it is hard to do UI update in ViewModel.


Aug 20, 2009 at 4:08 PM

What type of update were you thinking of that could not be handled by the MVVM pattern? I am sure there are some that will be significantly difficult to implement (and may not be worth it) but if you have a specific example, we may be able to suggest a solution. I had one challenge a while back where I needed to trigger a UI transition / storyboard to happen after an event that the user did. So what I ended up with is a State property on the VM and created a new TransitionManager control that I bound to my state which the name was the VisualState name to transition to. This would them cause the transition to happen on the UI without the need for access directly to the view.