Results 1 to 7 of 7

Thread: Why have both View Controllers and View Models in MVVM?

  1. #1

    Default Why have both View Controllers and View Models in MVVM?

    I'm very familiar with MVVM, having worked with the pattern in WPF/Silverlight as well as with Knockout.JS. I haven't tried building anything with Ext JS 5 yet, but attended Arthur's webinar today.

    In those other MVVM systems, the View Model contains behaviors/commands which are also bound to the view via data binding, so I've never had a need for a separate View Controller class.

    Why is Ext JS 5 structured as MVVM+VC instead of simply MVVM? Why should there be a separate class for handling behavior outside of the View Model?

    It seems like adding a View Controller on top of MVVM adds unnecessary complexity to the pattern.

  2. #2
    Sencha Premium User
    Join Date
    Nov 2010
    Location
    Chicago
    Posts
    2,425
    Answers
    20

    Default

    VCs are optional. Not all Views in MVVM require a ViewController.

  3. #3

    Default

    I understand that VC's are optional. My question is more along the lines of why are they ever needed? Why not simply expand the databinding to handle events within VMs?

    I've never seen View Controllers within the MVVM pattern, so I'm wondering why Ext JS added this extra thing on top of MVVM.

    I don't see how splitting the View Model part of MVVM into View Model and View Controller is a good thing. I'm clearly missing something here.

  4. #4
    Sencha Premium User
    Join Date
    Nov 2010
    Location
    Chicago
    Posts
    2,425
    Answers
    20

    Default

    Quote Originally Posted by CoderDennis View Post
    I don't see how splitting the View Model part of MVVM into View Model and View Controller is a good thing.
    Can you detail your concerns?

  5. #5
    Sencha Premium Member
    Join Date
    May 2010
    Location
    Guatemala, Central America
    Posts
    1,560
    Answers
    13

    Default

    I'm clearly missing something here.
    Simply: That's the way Sencha decided to implement MVVM.

    And I think is a good thing: keep code separated.
    Sure sometimes will feel as too over engineered.

    Regards.
    UI: Sencha Architect / ExtJS 4 - 6
    Server side: JEE / EJB 3.x / CDI / JPA 2.x/ JAX-RS / JasperReports
    Application Server: WildFly / Weblogic
    Databases: Oracle
    / MySQL / DB2 / Firebird

    If you like my answer please vote!

  6. #6
    Sencha Developer
    Join Date
    Sep 2008
    Location
    Antioch, IL
    Posts
    1,516
    Answers
    99

    Default

    After speaking with our dev team, here's the best answer I can share. Using ViewControllers in MVVM isn't really MVVM... it's more of a hybrid of MVC+VM.

    You can use ViewControllers and ViewModels together but that is not strictly MVVM anymore. Probably "MVC+VM" if we must name the mixture. The decision comes down to how much logic a ViewModel can rightly off-load from your View and if you then decide you want to push non-ViewModel logic off the View you can use a ViewController.

    We created ViewControllers for MVC reasons and ViewModels for MVVM reasons. We don't have (overly) strong opinions on what you should use or not in combination. These play well together or apart.

    Our analog to "Commands" are listeners with methods on the View (using defaultListenerScope config in pure MVVM). These methods can handle the command or delegate to the ViewModel.

    If you add a controller instead, then these methods live on the ViewController. If you have a ViewModel as well you can call methods there or just handle them in the ViewController in an MVC manner.
    Hopefully that answers your question.

    Like I said on Twitter, I don't know Knockout or WPF/Silverlight at all... but I don't think our dev team tried to duplicate any one specific approach.

  7. #7
    Sencha Developer
    Join Date
    Sep 2008
    Location
    Antioch, IL
    Posts
    1,516
    Answers
    99

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •