CAB Best Practices

最新推荐文章于 2020-12-23 13:37:51 发布

原创最新推荐文章于 2020-12-23 13:37:51 发布 · 637 阅读

CC 4.0 BY-SA版权

文章标签：

There should be a 1–1 relationship between a view and it’s presenter. Presenters are seen as an implementation detail of a view so nothing outside of the view should know about the presenters existence. [CreateNew] is your friend when it comes to creating a presenter for your view.
Since views know about their presenter (and vice versa) any work that needs to be done by the view should be directly delegated to it’s presenter. The presenter should handle all work that the view needs done. The view should just display data and be extremely “light”. The event broker should NOT be use to communicate between a view and it’s presenter.

private void button_Click(object sender, EventArgs e) {
_presenter.DoMyButtonClickStuff();
}

If views need to “communicate” between each other they should use EventPublication/EventSubscription.
WorkItem’s sole purpose in life is to be a container. Rather then being anything “Use Case” related treat WorkItem as what it is, a container.
The logic necessary for adding views, services, and etc. to a WorkItem should live inside a Controller class. Since the controller needs to know about it’s WorkItem the ControlledWorkItem class should become one of your good friends.
Controllers are used to get things wired up and running, and for adding everything necessary to the container (aka WorkItem).
If possible your views should implement the ISmartPartProvider interface. This allows the view to determine how it is displayed within your workspace(s).
Views and Presenters should implement IDisposable so they can be cleaned up properly.
The Guidance Automation Toolkit is your friend. Learn it, live it, love it!