Where do business logic and data belong in MVVM/Knockout?

[Justin]

I'm working on a feature-rich single page app with lots of Ajax. We've partially implemented MVVM with Knockout, but I want to clean things up and draw clear lines as to what belongs where. Searching the web has left me with lots of vague answers and conflicting opinions. To that end, I have two questions:

First, what exactly belongs in the Model? In almost all the Knockout example apps I've seen, the ViewModel holds data in observables and the Model is often completely missing. If the model doesn't hold data, then what is it for? 

Second, where does business logic (such as our client performs) that doesn't touch UI belong in the MVVM pattern? It seems like it doesn't has a home.

With the amount of work our application does with data, it feels like the Models should hold the weight and the ViewModels should stick to a lightweight translation role. I'm struggling with the fact that our ViewModels are massive while our Models are tiny. Currently our Models consist of data validation, Ajax calls, and virtually nothing else.

From what I've seen two things are allowed in the Model: raw data, and validation. Is it reasonable for me to want to place observables and functions that manipulate them in the Model, or does that totally violate the pattern?  And while I'm at it: the View is generally accepted to be markup and data-bindings. Can functions be part of the View? I'd like to place pure UI operations there. Essentially I'm finding the View=Markup, ViewModel=Code, Model=Data paradigm to be too restrictive in my current project. I'd rather base the separation on assocation/role than asset type.

The ViewModel's responsibility would shift from the current "pretty much everything" to screen flow and data translation.

Any thoughts are appreciated. Thanks!

[Michael Latta]

I would recommend the following architecture:

1) Place all DOM related data in view models using observables.  All data is held within observables, but the view model manages them and any computed values based on them.

2) Place any pure business logic in supporting objects / functions that the view model can call from computed observables.

3) Place all AJAX logic in separate objects that send and retrieve data then pass that data to the view model to be used to update the observables, or the reverse, get data from the view model when updated to send to the server.

4) A big part of properly structuring view models is using OO design principals to properly structure each with a constructor so they are not just raw javascript objects.  This allows the creation of computed observables more reliably and makes them easer to work with.  I would also suggest that each "class" or constructor be in its own file for the most part.

That keeps things well organized and allows reuse of the business logic as needed.

--
You received this message because you are subscribed to the Google Groups "KnockoutJS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to knockoutjs+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Justin]

Thanks for the input! Where do models fit into the picture?

[Michael Latta]

In Knockout a ViewModel is an object that holds observables (simple observables, observable arrays, and computed observables).  It serves as a focus for bindings to the DOM.  The reason to have sub-models is to work with the with, foreach, and template bindings that allow you to have nested contexts.  So they hold data (indirectly thorugh observables), and hold logic for updating the values of observables from other observables, and they are the focus for the bindings that map data to DOM elements.

Michael

[Justin]

Right. What I was trying to point out is that the Model part of MVVM seems to be rolled into Knockout's version of a view model. This might be technically accurate and needn't be "wrong" when you consider an observable is a function that can take in data and pass it to the view -- which is a view model's job. It's just that since the data resides "in" the function, it takes away the need for a separate model entirely. Trying to clarify things.

With your mention of supporting objects above, it feels like the source of my woes might be my attempt to force things into the pattern that are meant to exist outside of it. Is MVVM not meant to be an all-encompassing "everything in your app should fit into one of these slots" pattern?

Thanks!

[Michael Latta]

I consider the domain model part of MVVM to reside in the server if that is the focus of the question.

Michael

[Justin]

Interesting -- I hadn't thought of it that way.

Any thoughts on app components existing outside the strict definitions of MVVM?

[bhp.lib]

This may help ....

http://wekeroad.com/2012/08/12/avoiding-messy-situations-with-knockoutjs-and-javascript

[r.g...@clt-services.com]

can you explain point 4 ? 

thanks

[Nick]

Here is how I've structured my ko apps:

data models:
These are objects with observables that match exactly to the structured data from the server.
These models are *stupid*--they have no methods, no business logic, no knowledge of how to send or recieve themself from the server, they merely represent the data. I store these in a single place (SPOT), and all of the view models reference these.

"view models 1":
These are objects that wrap data model objects 1:1, adding visual embellishments such as display conversions (uppercase, concatenate names, modify units, provide field validation if appropriate here as opposed to in "view models 2").

"view models 2":
These are the actual model controllers--they are the UI, showing lists of "view model 1"s, or individual "view model 1"s.
These expose the actions that can be performed on the data models entities, manage UI interactivity states re a specific activity (searching/sorting/filtering/editing/creating/etc).

root view model:
This is the "app"--the main controller, routing, navigation, server communication/marshalling, all app-wide concerns can be exposed and wrapped here.

[Chris Russell]

Justin, I had the same set of questions when trying to figure out how to structure an SPA with a complicated data model, lots of client-side functionality, and lots of views of various slices of the data. I've been working on a solution you might find interesting that leverages a pattern called Model-Store-Observe-Feedback-Signal in conjunction with MVVM (via Knockout). I wrote a blog post about this recently here: http://blog.chrisrussell.net/2013/11/08/todomvc-model-view-whatever-and-msofs/

Regards, Chris