Best way to publish the contract of a SmartPart.

Topics: CAB & Smart Client Software Factory
Jul 1, 2006 at 12:07 PM
originally posted by: aras03k

Hi,

I'm looking for a nice and consistent way of "documenting" the interface of my smartparts. In my CAB app my workitems and smartparts will communicate through the eventbroker and the workitems will in many cases be responsible for setting up the business data in its state collection. We are going to be multiple independent dev teams working on different modules, and I want to find a nice way of reusing smartparts across these teams. To do that I want to find a way to document what events a smartpart can receive and publish and what objects it expects in its state bag. This way, when a dev drags a smartpart onto his workspace he knows exactly what "contract" he needs to obey for the smartpart to function. Is using XML documentation tags on the View the best way to go about this or is there a more intuitive way?

Any suggestions are more than welcome.
Jul 1, 2006 at 1:07 PM
originally posted by: ChrisHolmes

You're asking for two things that I see. (a) A contract for the View to know what EventBroker Events a SmartPart can listen to and publish, and (b) a contrac to know what should be in its State bag.

I can only guess you're not using the MVP/MVC pattern then, or these sorts of questions are taken care of. You may want to look into implementing the MVP pattern, because then you can reuse the views easier.

Our project implements MVP. Because of this, the State bag is taken care of (the Presenter inherits from the Presenter class, thus giving it direct access to a WorkItem's State bag).

As far as the contract goes: the View implements an interface that all other objects use when it comes to interacting with the View, including the Presenter. This means that no one has to know anything about the implementation of the View or what is going on under the covers. Because other objects interact with an Interface, the Views do not subscribe or publish any EventBroker events. Instead, it communicates only with the Presenter directly via method calls.

The Presenter actually handles the communication with the WorkItems via the EventBroker events. It has a reference to the View, but only via the Interface. In this way, the View is really a very dumb object that simply has data pushed into it, or pushed/pulled out of it. And since it implements an Interface, it is easy to determine what sort of Data should be pushed into it, because of the type declared in the methods.

If you truly wante to reuse Views of this nature, you should probably have the Presenter implement an Interface as well, and only have the View communicate via that Interface. Then you could reuse the View anywhere, with different Presenter implementations for different modules.

So one development team could use MyView with an IMyView implementation and a MyPresenter1 implementation of IMyPresenter interface. A second development team could use the same view, MyView, and implement a different Presenter, MyPresenter2, using the same IMyPresenter interface. Then each development team could implement the specific Presenters - wiring up different EventBroker events as necessary, communicating with different items, etc. They would know via the Interface definitions of the View and Presenter what kind of data the two use to communicate with and what form it needs to be in (maybe a DataSet, etc.).

Done this way, the whole thing is fairly self-documenting and easy to understand.