tag:robotlegs.tenderapp.com,2009-10-18:/discussions/robotlegs-2/9319-mvcscrud-workflows-revisitedRobotlegs: Discussion 2014-04-28T08:11:45Ztag:robotlegs.tenderapp.com,2009-10-18:Comment/312254122014-01-22T15:10:46Z2014-01-22T15:10:46ZMVCS/CRUD Workflows - Revisited<div><p>Hi Tim,</p>
<p>I think that all of the scenarios mentioned by Rick are valid
approaches. It's been said a million times already, but it's true,
it depends on your project's requirements and settings which
approach you'll choose. Whether your application will be well
structured and following all the "good practices" depends a lot on
your own experience. In fact, you don't need a framework at all to
achieve those goals:)</p>
<p>I like Promises, but I've never had a chance to use them in my
projects.</p>
<p>I agree with Rick on not always needing a Model.<br>
He said: "Typically I prefer to always get a fresh list of value
objects after a crud operation (someone might have made recent
changes to other contacts while you were working.)"<br>
I had situations where that's exactly what happened. The data has
been synchronized on the server and already "prepared" (ready to be
presented by a View), so when the Service received it, it just
dispatched an event with the results as a payload and the mediator
would then forward it to its view. Since the data wasn't shared by
other views and didn't affect the state of the entire application,
there was no need to hold or manipulate the state of that data in a
Model. Every user interaction triggered a command -> service
call, and every service result updated the view.</p>
<p>In most cases, though, I follow the 'classical' way of keeping
the state of data or manipulating it in a Model, and strongly-type
and transport it via VOs.</p>
<blockquote>
<p>When would it be essential to keep a list of VOs in a model for
example?</p>
</blockquote>
<p>An example for that situation is Joel's AddressBook. You can see
the contacts list in one view and an editable contact corresponding
to a Contact VO in the details view.<br>
The 2 views share the same data, but present it differently.
Changes made in the details view would be reflected in the list
view. Strong-typed collections are easier to work with, to inject
or/and maintain/change.<br>
But, I'm not sure that that was what you've asked, because I guess
you knew that already.</p>
<p>I hope others will participate in this discussion as well :)</p>
<p>Ondina</p></div>Ondina D.F.tag:robotlegs.tenderapp.com,2009-10-18:Comment/312254122014-02-10T20:59:05Z2014-02-10T20:59:05ZMVCS/CRUD Workflows - Revisited<div><p>Thanks Ondina. Of course, you're right - it always depends on
the needs of the project. I guess I'm always looking for a
combination of clarity, efficiency, economy and elegance in my
projects, but there's no perfect or single solution. Your comments
have been very helpful. Thanks!</p></div>timwjohntag:robotlegs.tenderapp.com,2009-10-18:Comment/312254122014-02-11T14:48:59Z2014-02-11T14:48:59ZMVCS/CRUD Workflows - Revisited<div><p>Hey Tim, you're welcome!<br>
I'm sorry that the participation rate in this discussion is so low.
It's always interesting to hear different approaches to a problem,
all the more so as there isn't a single perfect solution.</p></div>Ondina D.F.