SCSF MVP Study Notes

 

A real-word sample of MVP

One small software company, when customer have problems they will call technical support team to solve the problem.

 

1 years later, the company's business become more, they identify one helpdesk team to collect customer's problem and then the helpdesk will look for corresponding technical support people and pass the problem the person, once the person solved the problem he will feedback the helpdesk and helpdesk will response to user on the result.

 

Now, the company's business become more and more, and the technical support team become bigger and bigger, it will become tire work for helpdesk to know and found out the correct support person to solve specific problem as well as track the process, because there are so many business area and technical support people, also there is so many controversy from technical team on workload and who should take which problem. To solve this issue, then company set up a corrdinter team to assign the problems to corresponding technical people and track the process and collect the result from the technical support team and update helpdesk team.

 

In this sample:

M: the technical support team

V: the helpdesk team

P: the corrdinter team

  

View

1. View should only publish below 3 things to presenter through interface
   1. Attributes: for data which collect from user
   2. Attributes: for data which used to display to user
   3. Events: for actions triggered by user

2. Never publish controls to Presenter or allow Presenter access any UI element in View

 

Presenter

1. Presenter should register the events publish from the view (through interface) and invoke corresponding module service to handle it and then response to view through update the data attributes when necessary.
2. Presenter should never tell view how to display it should handle by view itself, should only update the data of view which used to show user.
3. Presenter should never do any business logic (e.g. validate, treatment, save and update of data), it is module's work

 

Module

1. Module handle actual business logic, only Presenter can communicate with it.

  

Advantage of MVP

1. Can split UI development team and business development team, so UI team can only focus on UI layout, logic, validations, so the team only need to know the requirement of UI and also the guideline of UI development.  And also it will make it possible to split the testing of UI and backend.
2. vice versa.

 

Steps of how to use the MVP in project

1. Define the Interface
   1. Understand the UI design from use case
   2. List out the data need display to user, define the attributes for them
   3. List out the data will collect from user, define the attributes for them
   4. List our the user actions, define the event for them

2. Implement the View
   1. Implement the attributes and events defined in interface
   2. For the data attributes which need display to user, implement how to display on set method
   3. For the data attributes which collect data from user, make sure it can be update in time, one solution is set before submit, but suggest to use data binding which implement 2-ways on-line synchronization.
   4. For user actions, e.g. button click, dropdown list selection change, raise corresponding events.

 

3. Implement dummy Presenter to provide dummy data or event response to view
4. Conduct UI part Testing
5. Implement actual business logic in Presenter and module
6. Conduct business part testing
7. Conduct integration testing

 

  

Maybe my understanding is wrong because it is totally violate the design role on point 11 and 12 of http://kjellsj.blogspot.com/2008/05/design-rules-for-model-view-presenter.html, but actually I can't understand why and I still feel my understanding is more clear. Anybody can help correct me?

11. The interface should contain methods only, no properties - afterall the presenter drives the use-case, not data

12. All data in the MVP component should be kept in the model, no data should exist as properties of UI controls only