23
1 Code Camp 06’ Presentation – Model View Presenter Design and Implementation Chase Thomas Consultant - MCSD.NET - Digineer Inc.

Code Camp 06 Model View Presenter Architecture

Embed Size (px)

DESCRIPTION

This is the slide show I created for the first Twin Cities Code Camp in November of \'06 - I did this when I was working for Digineer and also used it in a Digi-U session that I put on for the other consultants.

Citation preview

Page 1: Code Camp 06   Model View Presenter Architecture

1

Code Camp 06’ Presentation – Model View Presenter Design and

Implementation

Chase ThomasConsultant - MCSD.NET - Digineer Inc.

Page 2: Code Camp 06   Model View Presenter Architecture

2

Model View Presenter Architecture

The Model View Presenter is a user interface The Model View Presenter is a user interface architecture similar in nature to the model view architecture similar in nature to the model view controller. One of the greatest strengths in the controller. One of the greatest strengths in the MVP design is the ability to unit test user interface MVP design is the ability to unit test user interface logic without a user interface.logic without a user interface.It’s origins are from the Taligent programming model for C++ and Java (based on the Smalltalk MVC) and has seen various implementations since it’s introduction. You can read more about the origins of MVP at the following URLs…

ftp://www6.software.ibm.com/software/developer/library/mvp.pdf

http://www.object-arts.com/papers/TwistingTheTriad.PDF

Page 3: Code Camp 06   Model View Presenter Architecture

3

Traditionally The View has a dependency on the Traditionally The View has a dependency on the model. The view directly interacts with the Model model. The view directly interacts with the Model and the controller directly interacts with the view – and the controller directly interacts with the view – controlling complex UI logic and data mapping.controlling complex UI logic and data mapping.

Classic Model View Controller (MVC) Architecture.Classic Model View Controller (MVC) Architecture.

Model View Presenter Architecture

Page 4: Code Camp 06   Model View Presenter Architecture

4

Model View Presenter Architecture

• Known issues with this approach• A lot of logic for interaction with the model is coded into the

view – this makes testing the interaction between the view and the model difficult without an automated test script or manual user testing directly on the User Interface.

• The Controller is directly communicating with the view instead of an interface of the view making unit testing via the controller without an ugly automated UI test script impossible.

• The Controller knows what it’s view is – so if you want to re-implement the UI logic into a different UI (web interface as opposed to windows interface) you will need another controller that specifically interacts with your new View.

Page 5: Code Camp 06   Model View Presenter Architecture

5

Model View Presenter Architecture

Why Model View Presenter?

•Further decouples the UI manipulation logic from the UI implementation by using an interface.

•Separating the UI from the presenter makes it possible to implement the UI interface on other things like unit tests. This also allows reuse of our presenter with multiple view types that implement the interface.

•Removes all dependencies the UI once had on the model.

•Forces developers to put interaction between the UI and the model within the presenter since you cannot interact with the Model from within the View.

Page 6: Code Camp 06   Model View Presenter Architecture

6

Model View Presenter Architecture

Model View Presenter (MVP)How it works…

1. The view sends calls to the presenter for getting objects – saving – etc…

2. The presenter manages the model and issues changes to the model instances by interacting with the IView interface

3. The model fires events back to the presenter notifying it of the current state of the model based on any changes that were made

4. The presenter can then choose to continue interacting with the model or may also interact with the view via the IView Interface.

Page 7: Code Camp 06   Model View Presenter Architecture

7

Model View Presenter Architecture

Architecture UML (Class Diagram)

Page 8: Code Camp 06   Model View Presenter Architecture

8

Model View Presenter Architecture

Architecture UML Diagram (Sequence – Loading an Employee Model)

Page 9: Code Camp 06   Model View Presenter Architecture

9

Model View Presenter Architecture

Architecture UML Diagram (Sequence – Changing a value in the UI)

Page 10: Code Camp 06   Model View Presenter Architecture

10

Model View Presenter Architecture

Implementation in C# (.NET 2.0)

Building the model objects

The core responsibility of the Model within and MVP is notifying the presenter of changes and managing it’s own data access and validation.

Some business object frameworks are already available with this notification functionality built in and are easy to extend for data access and validation.

•CSLA.NET

•Gestalt

Implementation of the INotifyPropertyChanged interface (part of the System.ComponentModel namespace) is another option that works if you want to roll your own solution for the Model.

Page 11: Code Camp 06   Model View Presenter Architecture

11

Model View Presenter Architecture

Implementation in C# (.NET 2.0)

Building the model objects – Using Gestalt

Page 12: Code Camp 06   Model View Presenter Architecture

12

Model View Presenter Architecture

Implementation in C# (.NET 2.0)

Building the model objects – Using CSLA.NET

Page 13: Code Camp 06   Model View Presenter Architecture

13

Model View Presenter Architecture

Implementation in C# (.NET 2.0)

Building the model objects – Simple INotifyPropertyChanged Interface Implementation

Page 14: Code Camp 06   Model View Presenter Architecture

14

Model View Presenter Architecture

Implementation in C# (.NET 2.0)

Defining Our Interfaces…

Every view needs to have an interface that will be used by the presenter to interact with it.

Things to think about…

•Complex UI logic – what the presenter will need from the view in order to properly handle the interaction between the two.

•What User interface elements will be exposed to the presenter?

•Are we going to use data binding?

Page 15: Code Camp 06   Model View Presenter Architecture

15

Model View Presenter Architecture

Implementation in C# (.NET 2.0)

Defining Our Interfaces – IEmployeeView Interface

Page 16: Code Camp 06   Model View Presenter Architecture

16

Model View Presenter Architecture

Implementation in C# (.NET 2.0)

Building the Presenter…

What needs to happen here…

The presenter needs to tell the View information about the model and contains all the complex UI logic such as…

•The presenter maintains the model reference so any models used in a given UI will be encapsulated within the presenter – the view does not directly access the model - EVER

•Model data is handed off to the view via the IView interface for display by the presenter.

•The presenter maintains synchronization between what the view displays and the model data – it also sets state based on error conditions – and other scenarios

Page 17: Code Camp 06   Model View Presenter Architecture

17

Model View Presenter Architecture

Implementation in C# (.NET 2.0)

Implementing our View Interface (part one – the Windows Form)…

Implement the IEmployeeView interface on the windows form – the windows form implementation will receive information from the presenter and utilize it to perform display tasks.

Page 18: Code Camp 06   Model View Presenter Architecture

18

Model View Presenter Architecture

Implementation in C# (.NET 2.0)

Implementing our View Interface (part two – the UI Unit Tests)…

Implement the IEmployeeView interface on the unit test class that has the TestFixture attribute applied.

Within the unit test class you will need to create placeholder values for what the windows form user interface state (i.e. control colors – error messages – enabled / disabled state etc…).

The unit test in essence becomes a Windows Form simulator. If you did it right – there will be nothing missed by using a Unit test in place of a windows form.

Page 19: Code Camp 06   Model View Presenter Architecture

19

Model View Presenter Architecture

“Blind Data binding”

Problem:

Since the view knows nothing about the model – how can we bind the view to our objects?

Solution:Create a windows custom binding source object pass the binding source object to our presenter.Finally: Once the presenter has a reference to the windows forms Binding Source - establish the data bindings between the controls and the object in our form code.

Page 20: Code Camp 06   Model View Presenter Architecture

20

Model View Presenter Architecture

Implementation of “Blind Data binding” in C# (.NET 2.0)

Create and pass our binding source to the presenter

Page 21: Code Camp 06   Model View Presenter Architecture

21

Model View Presenter Architecture

Implementation of “Blind Data binding” in C# (.NET 2.0)

Establishing the Data bindings from our viewThe one of the cardinal rules of the MVP is that the View cannot know about or have a reference to the Model.

That does not mean we can’t look at our Model property names and set up bindings in the form.

We have not retained any knowledge of the Model within our presenter by doing this – just string values – you could even keep these values as constants in the presenter to centralize the information.

Page 22: Code Camp 06   Model View Presenter Architecture

22

Model View Presenter Architecture

What is the Supervising Controller and Passive View?

http://www.martinfowler.com/eaaDev/SupervisingPresenter.html

The 10 second description of these two derivations of the MVP are that they vary in how much interaction the view has with the model.In a supervising presenter the model is exposed to the view in order to perform data binding or other simple data to UI mapping.

http://www.martinfowler.com/eaaDev/PassiveScreen.html

A passive view is closer to what we just discussed with the original MVP. The view has no dependence on the Model whatsoever. The presenter handles all data mapping between the UI and Model

To describe these two “new” concepts is beyond the scope of this presentation – however since they are now the recommended approaches according to Fowler’s website, a brief explanation of the two are in order…

Page 23: Code Camp 06   Model View Presenter Architecture

23

Model View Presenter Architecture

Sources of Material

http://www.martinfowler.com/eaaDev/uiArchs.html

http://www.martinfowler.com/eaaDev/SupervisingPresenter.html

http://www.martinfowler.com/eaaDev/PassiveScreen.html

http://msdn.microsoft.com/msdnmag/issues/06/08/DesignPatterns/