tag:robotlegs.tenderapp.com,2009-10-18:/discussions/questions/399-terminology-question-data-object-somewhere-between-model-and-voRobotlegs: Discussion 2018-10-18T16:35:21Ztag:robotlegs.tenderapp.com,2009-10-18:Comment/46129262011-01-07T09:55:37Z2011-01-07T09:55:37ZTerminology question: data object somewhere between Model and VO.<div><p>I still call a model a model, whether it extends Actor or
not.</p>
<p>That's an interesting thought though - whether it should be
reserved for models that extend Actor. I hadn't really thought
about it before and I probably should have. I'll be interested to
see what other people think.</p></div>Straytag:robotlegs.tenderapp.com,2009-10-18:Comment/46129262011-01-07T17:12:15Z2011-01-07T17:12:15ZTerminology question: data object somewhere between Model and VO.<div><p>I don't personally think the definition of "model" should be
based on<br>
whether it extends Actor or not, since "model" obviously
pre-dates<br>
Robotlegs. Not to mention that even in Robotlegs there's no rule
that<br>
your "model" classes need to extend Actor -- it's just there as
a<br>
convenience.</p>
<p>Having said that, I can understand the question that's being
asked and I<br>
agree that in many cases I've mentally designed apps where the VOs
are<br>
"long-living containers of state" and not just "snapshots passed
along with messages." The VOs don't just represent snapshots of
data that are<br>
passed around with messages. Instead they represent model objects
in a<br>
true 1:1 way. You never pass a "clone" of the VO -- always the real
VO.<br>
If you change a property of one of those VOs the VO itself
dispatches a<br>
change event so parts of the app that use it update themselves. A
key<br>
benefit I see to this approach is that it gives you a nice way to
deal<br>
with the situation where you have a collection of objects that are
each<br>
represented by a view (each view having its own mediator). Rather
than<br>
sending the change event to every single mediator and forcing them
to<br>
check an id to see if they are the one single object that changed,
the<br>
mediator can just listen for changes on the "VO" itself and then
only<br>
the one mediator gets the change.</p>
<p>But this is really all just a half-formed idea in my head. I've
never<br>
actually built a RL app using that technique, so I don't know how
well<br>
it would actually work out. But I keeping coming back to that
pattern in<br>
my head, so I'll probably do it someday soon.</p>
<p>Paul</p></div>Paul Robertsontag:robotlegs.tenderapp.com,2009-10-18:Comment/46129262011-01-11T13:58:46Z2011-01-11T13:58:46ZTerminology question: data object somewhere between Model and VO.<div><p>I never have the need to extend actor in model, especially when
I use signals in models</p></div>Nikos tag:robotlegs.tenderapp.com,2009-10-18:Comment/46129262011-01-11T15:19:51Z2011-01-11T15:20:13ZTerminology question: data object somewhere between Model and VO.<div><p>So are pretty happy injecting the model directly into your
views?I prefer to have clones, especially when I'm using ADG's an
grouping collections bound to arraycollections (the model
clone)</p></div>Nikos tag:robotlegs.tenderapp.com,2009-10-18:Comment/46129262011-01-11T15:30:06Z2011-01-11T15:30:07ZTerminology question: data object somewhere between Model and VO.<div><p>Yes, I feel fine injecting model intro mediator. For simple
cases model as it is, for more complex ones via interface.</p></div>pavel.fljot