PDA

View Full Version : MVC event with lots of properties


asciiman
05-16-2009, 08:13 PM
Hi all,

I have a view component which pulls in about 15 different properties from the model. There is another view component which provides user controls (sliders, text input, etc) for each of the properties in the first view. When the user modifies one of the controls I want to fire an event which sends the updated control data to a listening command, who updates the model, instantly updating the first view.

Having 15 events/commands seems like overkill. I'd like to have one event (PropertyUpdateEvent) which takes as data the property that was changed and a command which listens, sees the property that changed and updates that property in the model.

What I don't know is how to organize the property data inside the event. I have two ideas:

1) I could have one event with 15 properties all set to null and a view which instantiates the event setting only the property that was modified and leaving the rest of the (non-modified) properties as null. (The event should fire as soon as one property is changed. So only one property at a time will ever be changed.) Then the command will just update any non-null property. This approach seems to be sending a lot of data, even though only 1 property at a time will be used.

2) I could have the event accept a key (property name) and value (property value) and pass it to the command. But this approach seems rather loose.

3) I could wrap the property data (name and new value) in some kind of container object. The container would know about all of the possible property names (as string consts) and can be constructed with a valid property name and it's new value. This seems tighter than #2, but then both the view and model would need to know about the container object. Is this fair in MVC?

Is there a better way?

asciiman
05-16-2009, 08:25 PM
Funny how after a while of thinking, I need to actually write the post to answer my own question.

The answer is #3. I just remembered the use to Value Objects (VO) which I believe is exactly the kind of container I need to use to pass this info.