ModelView vs Controller clarification

If we set aside angular for a second and strictly look at MVVM, we see that it is a common design pattern. A design pattern gives us,  a “cookie cutter” approach to solving common development problems. Really as developers, we are constantly fighting complexity. Our goal should be to write software that is clear, concise and maintainable. These patterns strive to bring structure and sanity to our applications so that we can solve them in the cleanest method possible.

Ok, so enough about patterns. Back to MVVM. This pattern can be implemented differently by various frameworks in completely different ways. However, the core fundamental idea behind them would be the same. That is that we would have

  • Model
  • View
  • ViewModel

Ok, so on its own, this may seem rather abstract. Let’s bring in angular and add some context. So how does angular implement MVVM? Let’s assume we have the following code.


Here we have an application that contains a view, a controller and some data that we want to render. We also included an input field that allows a user to type their favorite programming language. So let’s break down this page to show the components used and how they related to MVVM.

Model – represents and holds raw data/ Data/Business Logic

Our data here is ‘John Flores’ which is being stored in `$scope`. We also have a variable that is storing a users favorite programming language. This would be another piece of raw data would is associated to the model. We are not concerned with how this data will be rendered. We just care that we are storing it and that we have access to it. You will also notice that the description in the lecture for `Model` also includes business logic. Well, to illustrate that, suppose we have an object called `userService` that is responsible for returning to us a users full name. So let’s take that the controller we defined above and slightly modify it to include the following:


Note that for the sake of explaining this, I’ve commented out the controller portion. I would like you to focus on the aspects that deal strictly with the raw data.

Again, we are dealing with data only. The `userService.getFullname()` method may contain business logic that ensures data is formatted properly or that we are inputting the appropriate content. Or maybe it will fetch data from an external resource using ajax. Again, we are strictly focused on storing and handling the raw data and not worried about where it will be placed in a view.

View – UI/Presentation/ UI declares events

We now arrive at the view. In an abstract sense, the view only displays the data it is given. In our example above, the view is the following:


  • In a web app, it’s just the HTML and CSS
  • Only displays data that it is given
  • Never changes data
  • Decoratively broadcasts events

So we see that we have HTML (and css if we have stylesheets or inline styles) to render our styling. We see that we have the expression`{{fullname}}` that is displaying our`fullname` from the value that is being stored in the scope. Notice that the view doesn’t actually change any data. Yes, we have an `ng-model` attribute on an input field that updates the `favoriteProgrammingLanguage` scope value to whatever the user is typing but that is being achieved by the declarative bindings that may broadcast events. In the template, since we’ve placed <input type=”text” ng-model=””/>, we are telling angular to bind the expression in the ng-model=”favoriteProgrammingLanguage” attribute to the scope. So as the user types, the ng-model attribute is performing logic that is updating the `favoriteProgrammingLanguage`. However, the html template doesn’t care how that’s happening. All it knows is that it will render whatever value is inside of `favoriteProgrammingLanguage`.

ModelViewRepresentation of the state of the view

We’ve reached the last point. The ModelView. Recall that the ModelView represents the state of a particular view. What does that mean? So angulars implementation of ModelView is achieved with ngcontrollers.

angulars concept of a `controller` is how you implement the ViewModel concept. Let’s show the controller code again:capture

The controller provides us the mechanism to manipulate data, inject objects that can do “stuff” for us, listen for events that are transmitted from the view (say a click handler, ng-model, or maybe a hover event) or call other functionality for additional business logic processing. In this case, our controller is using the `userService` object to delegate the responsibility of returning a properly formatted users fullname.

Lastly, how is this magic happening? This is where the Declarative Binder comes into play. This crucial process, which is handled by angular, binds the model (our data in $scope, userService) in our ViewModel (controller) to the view (our html template). As a result, we can easily do things like bind a controller to a view in our templates.



Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s