Web Part Design
The ExecutionModels.Sandboxed solution illustrates various best practices for the design of sandboxed Web Parts in SharePoint 2010. The following class diagram shows the structure of the AggregateView Web Part. This design is an example of the Model-View-Presenter (MVP) pattern, which is designed to isolate your business logic from the details of your user interface (UI).
The AggregateViewPresenter class represents the Presenter component in the MVP pattern. This class performs the following tasks:
- It retrieves a DataTable from the model represented by the IEstimatesService.
- It sets the DataTable as the data source in the view represented by IAggregateView.
The AggregateView class represents the View component in the MVP pattern. This class is the actual Web Part. This class performs the following tasks:
- It instantiates the Presenter object represented by the AggregateViewPresenter. To do this, it creates an instance of the Model represented by EstimatesService, and then it constructs the AggregrateViewPresenter, passing in itself as the View and the EstimatesService as the Model. This is an example of constructor injection.
- It renders the data supplied by the presenter to the UI.
Finally, the EstimatesService class represents the Model component in the MVP pattern. This class performs the following tasks:
- It executes a query to retrieve data from the Estimates list on each subsite.
- It returns the data to the caller in a DataTable.
The use of the MVP pattern increases modularity, flexibility, and testability of the application. If you want to display the data differently, you can modify or replace the view, without changing any of the business logic, by providing an alternative implementation of IAggregateView. In other words, you can create a view that displays the data in any way you want, as long as it exposes a public write-only property of type DataTable named SetSiteData. Similarly, if you change the way you store your SOWs and estimations, you can provide an alternative implementation of IEstimatesService without editing the view or the presenter. Finally, the design makes it easy to test your presenter logic by providing mock implementations of IEstimatesService and IAggregateView.
The following illustration shows how execution passes between the view, model, and presenter classes.
It is important to note that the view is relatively passive and is entirely driven by the presenter logic. The view class simply provides a forward-only property setter that the presenter can use to set the data source for the view.