Behavior represents a single reaction to an event. In most cases the event can be discarded as the behavior should represent 'what' aspect of the functionality not 'why'. Which means, that in behaviors focus is on the actual work that needs to get done rather than how it got triggered. In many cases this approach allows for an excellent separation of view from the underlying logic and allows for clean reuse of the functionality across the application. Behaviors could be of two kinds:
- business functionality related
- ui functionality related
Behaviors that are business functionality related should quickly delegate to the services tier and in most cases process the service response. They are unlikely to be tied to the specific event type. Behaviors that drive the UI functionality, for example trigger page transition, present popup information, are more likely to react to a specific type of the event. State should be transported to behaviors through the Dependency Injection. Ideally, behaviors should only interact with view models, using some to generate input for the services and updating some models with the service results.
@param < E> is actual event that given behavior will handle, in most scenarios this could be disregarded