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:

to carry the data from service to command,
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';
    ...

Is there a reason you are not using signals? https://github.com/robertpenner/as3-signals — ThanksBro, Feb 18 '13 at 12:30
The same question applies to signals, doesn't it? If I use the SignalMap I have to extend the Signal class and make a FooServiceSignal and BarModelSignal? — hidarikani, Feb 18 '13 at 12:44
With signals, I would call it BarServiceProductChanged and BarModelProductChanged or the same but with the Signal suffix. In the naming, the most important thing is to keep up with the same way you name stuff, and as you beginn to work in teams, you will agree on naming also. For example I used to put Signal suffix on all my Signals, but in group Project they dont use suffix on signals but only on commands so I play along. Just keep the same way in all your code. — ThanksBro, Feb 18 '13 at 14:59

score 0 · Answer 1 · answered Feb 23 '13 at 23:03

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.

hidarikani · Accepted Answer · 2013-03-07T07:34:18.687

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.

Event Duplication

2 Answers2