Creating Views from Model / Service VO's

Greg's Avatar

Greg

30 Jul, 2012 04:39 PM

This is a situation that I come across often, and never really feel like I have the optimum solution:

A) A Command calls a Service to fetch a collection of data objects.

B) The Service parses the returned data into value objects, and either passes them onto another Command via an event or signal, or assigns them to a Model.

C) This collection of value objects are required by a container view to populate itself with content, for example, a ScrollView that will build ScrollViewCells representing each of the value objects.

My value objects reside in my model package, as they are data, and I want to avoid the following when I dispatch the collection of model VO's to my ScrollViewMediator via some system message:

1) Passing the list of value objects from my ScrollViewMediator directly to my ScrollView API, to loop through and build the ScrollViewCell sub views, as I'm then referencing the model (value objects) in my ScrollView.

2) Doing any work looping through the collection in my ScrollViewMediator, as that's obviously a no no.

Should I build a list of ScrollViewsCells from my value objects in a Command, and dispatch these to the ScrollViewMediator? That seems to me to be the only solution, but then this feels like I'm doing view work in a command.

Would be really interested to hear some thoughts on this.

  1. 1 Posted by stuart on 30 Jul, 2012 11:34 PM

    stuart's Avatar

    What's wrong with (1)? I've always had no issue passing VOs to views.

    Otherwise, you could loop through the list in your mediator and call an API for the relevant data:

    for person in peopleList:

    scrollView.createScrollViewCell(person.id, person.name, person.age);
    

    Then the ScrollViewCell can store the ID, so if the "remove" button on a ScrollViewCell is clicked, the mediator can pass on the ID to the remove command, or whatever.

    But while not passing the actual VO avoids coupling, you're sort of coupled anyway: if you change person.age to person.birthday then you will have to go through and fix the mediator and views anyway. Passing the actual VO makes this relationship more explicit rather than pretending it's not there. I think of VOs as being light weight and suitable for passing around anyway; if passing the VO means the view is getting a lot of unrelated data then maybe the VO is taking on too much and should be split up anyway.

    I definitely wouldn't create views in your commands, what if you wanted three separate views to be creating different subclasses of ScrollViewCells in reaction to the same events? The command would quickly grow unwieldy.

  2. 2 Posted by stuart on 30 Jul, 2012 11:41 PM

    stuart's Avatar

    Sorry, I re-read your question and realised I used (2) as my proposed solution, why do you think this is a no no? If a mediator deals with a single VO, what is the issue with it looping through a list of them?

    You could loop through the list in the command and dispatch separate "this thing has been created" events rather than a single "a list of things has been created" event, I guess.

  3. Support Staff 3 Posted by creynders on 31 Jul, 2012 07:45 AM

    creynders's Avatar

    I agree with Stu. Why would it be a no-no to loop through the VO list in the mediator, but is it ok to do so in the view?
    Loop through the list in the mediator and pass the values to the view which in turn creates the appropriate view objects.

    That said, I do pass VO's to the view too, if two conditions are met: the view represents the VO data fully and the VO's are truly read-only.

  4. 4 Posted by wagster on 31 Jul, 2012 11:29 AM

    wagster's Avatar

    That is after all the whole point of VOs being immutable, no?

  5. Ondina D.F. closed this discussion on 25 Aug, 2012 02:42 PM.

Comments are currently closed for this discussion. You can start a new one.

Keyboard shortcuts

Generic

? Show this help
ESC Blurs the current field

Comment Form

r Focus the comment reply box
^ + ↩ Submit the comment

You can use Command ⌘ instead of Control ^ on Mac