MVCS/CRUD Workflows - Revisited

timwjohn's Avatar


21 Jan, 2014 11:30 AM

Hi guys,

I'm trying to devise a set of workflows I can refer to and rely on for different application needs.

I found the concepts, methods and rationales outlined by rickr in the opening post of this thread very helpful. Unfortunately it didn't spark the debate rickr was probably hoping for.

I think it would be beneficial (for me at least!) to hear about each other's approaches to various scenarios involving a CRUD based service. For example, in many cases a Model isn't necessary - it may be just fine to call a service from a mediator upon initialisation, and deal with the returned promise directly. That would certainly avoid confusion when multiple mediators are active at once. When would it be essential to keep a list of VOs in a model for example?

  1. Support Staff 1 Posted by Ondina D.F. on 22 Jan, 2014 03:10 PM

    Ondina D.F.'s Avatar

    Hi Tim,

    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:)

    I like Promises, but I've never had a chance to use them in my projects.

    I agree with Rick on not always needing a Model.
    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.)"
    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.

    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.

    When would it be essential to keep a list of VOs in a model for example?

    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.
    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.
    But, I'm not sure that that was what you've asked, because I guess you knew that already.

    I hope others will participate in this discussion as well :)


  2. 2 Posted by timwjohn on 10 Feb, 2014 08:59 PM

    timwjohn's Avatar

    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!

  3. Support Staff 3 Posted by Ondina D.F. on 11 Feb, 2014 02:48 PM

    Ondina D.F.'s Avatar

    Hey Tim, you're welcome!
    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.

  4. Ondina D.F. closed this discussion on 28 Apr, 2014 08:11 AM.

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

Keyboard shortcuts


? 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