Event Duplication

Question

In my Robotlegs app service results often have to be persisted in models. This creates event pairs that have identical payload types:

1. to carry the data from service to command,
2. to carry the data from model to mediator

I'm wondering how to name these events. Imagine I have a service:

FooService.getProducts()

Then I have a model:

BarModel.setProducts()
BarModel.getProducts()

What is the best way to name the event dispatched by the service after it retrieves the product collection?

What is the best way to name the event dispatched by the model after BarModel.setProducts() has been invoked?

Or maybe I should use a single event with two different types:

public class ProductEvent extends Event
{
    public const SERVICE_PRODUCT_CHANGE:String = 'serviceProductChange';
    public const MODEL_PRODUCT_CHANGE:String = 'modelProductChange';
    ...

Answer 1

I've made up my own naming scheme that answers my question.

First of all, most often events are used to propagate data between actors:

• service > model
• model > mediator
• mediator > model

Secondly, different events carry different data types. Thirdly, the same data often must be passed two times: service > model > mediator.

Based on this I've decided to name my event like this:

<class>Event_<payload>

Where class is the name of the class that dispatches the event and payload is the name of the public property that changed. For example:

• ProductServiceEvent_products
• ProductModelEvent_products
• ProductViewEvent_products

Each event has only one type called CHANGE.

Answer 2

With Services I like events/signals that indicate success or failure, since services often make contact with external resources which are prone to fail for various reasons.

MyServiceLoadSuccess and MyServiceLoadFailure

Even if your service quietly fails the idea of success makes sense for services, I think.

With models they tend to need to know how to transform data they can also fail but in reality they are making decisions and then preparing data for views or other models and are often just sending update.

MyModelUpdate

Obviously your specific situation is important to the semantics you choose but this is a pattern that I've found helpful and generally applicable to all kinds of situations.