Explore the implementation of the MVP (Model-view-presenter) design pattern under the SharePoint platform

For SharePoint developers, there is often too much focus on SharePoint platforms and tools, while the design patterns and code testability are placed at a lower priority. This is not to say that SharePoint developers is not interested in design patterns, but rather lacks the experience of using design patterns under a SharePoint platform. So this blog is as shown in the title: Explore the implementation of the MVP (Model-view-presenter) design pattern under the SharePoint platform. With the MVP design model, we can try to keep our projects separate, easy to test, reusable. In implementing the MVP, I will also join the repository and service locator design patterns, repository can be understood as a storage, equivalent to the data Access layer (DAL), and service locator played the role of IOC, IOC similar to a factory (container), the factory registered a lot of dependencies, the IOC container formal use of this dependency so that dynamic injection (also known as Dependency injection) to provide you with the necessary examples, so that can be effectively decoupled, that is, separation of concerns.

MVP mode

Under a SharePoint platform, such as the development of SharePoint Farm Solution, this code can often occur if the code is not refactored:

It's obvious that all the logic is mixed up in the UI Logic, especially in team development, which is not conducive to testing, but also not conducive to division of cooperation. And for SharePoint, the development machine performance if low, debugging is miserable, its time-consuming difficult to imagine. So if you can solve the bug through unit test, it will save time greatly. Fortunately, the advent of the MVP design pattern is ideal for Web Part development. The MVP feature is a good separation of attention points and their respective roles. Make a slight change to the image below:

You can see that the UI logic processing business logic to the presenter, and the UI is completely liberated, just do the display layer (View).

Repository Design

As you can see from the figure above, presenter does not directly access the SharePoint data layer (SharePoint List), but through a repository to indirect access, and repository Model encapsulates the data tier.

To this step, seemingly perfect, but in fact still in situ. Because presenter and repository are still tightly coupled, it's as if a programmer responsible for presenter has to wait for the Repository B programmer to do the job.

Who asked them to be tightly coupled together?

In team development, we need to be independent, so the programmer responsible for presenter can use Mockrepository to do the test, so that will not affect progress, fortunately, based on the design of the interface, can let me complete this vision. The specific implementation is as follows:

SharePoint Service Locator Design pattern

Careful analysis of the above figure, presenter is still not decoupled, because this must be in the presenter to create an instance of a repository, so presenter still rely on repository this project assembly. This is not good for testing ( as we have analyzed earlier, a programmer who develops presenter must be able to use mockrepository to test in a unit test and use the anyrepository developed by B programmers in real projects).

So is there a way to completely decouple presenter and repository?

Of course, such as dependency injection, this blog describes the IOC container developed specifically for SharePoint by Microsoft Patterns and Practices: SharePoint Service Locator.