AngularJS client MVC pattern?

Until now I was mainly using Struts 2, Spring, JQuery technology stack for building web applications. The point is, that mentioned stack uses server side MVC pattern. The main role of web browsers was limited to a request/response cycle (+ client side validation). Data retrieval, business logic, wiring and validation were mainly responsibilities of the server side.

I have few questions regarding AngularJS framework that were inspired by following quotes I've read:

From the AngularJS tutorial:

For Angular apps, we encourage the use of the Model-View-Controller (MVC) design pattern to decouple the code and to separate concerns.

From the Wikipedia Model–view–controller:

Model–View–Controller (MVC) is an architecture that separates the representation of information from the user's interaction with it. The model consists of application data and business rules, and the controller mediates input, converting it to commands for the model or view

AngularJS uses client side MVC pattern. So I guess there is no other option then to include validation logic also to the client side in some way?

What would be the best way to write a robust AngularJS application? MVC on client side and some kind of MC (model, controller) on server side?

Does that mean, that MODEL and CONTROLLER are in one way duplicated (client/server)?

I know my question is somehow weird, but I think the reason is, that I am somehow acustomed to traditional server side MVC pattern. I am sure there is someone, that have already done same transition.

Solution 1:

Not at all a weird question - I've been trying to sell Angular to a lot of java developers and they ask this. I asked it myself when I was learning (I'm still learning, btw)

If you take a 'conventional' java webapp as you've described and Angular-ize it, you've got to first take your server and make it a RESTful API. Remove the JSPs, etc. This is actually the hard part, IMO, of writing an Angular app - getting the REST API right. The key for me to deciding what logic needed to go into the server was thinking of it as a pure api and forgetting for the moment that it will have a front end.

That question really helped me - if someone tries to save a given resource and that resource doesn't have valid data there's no front end to tell them - they're hitting the API directly so the API needs to reject it. So, the back end is responsible for the deep validation. This applies to your business logic as well. Assume someone is using just the API and it will become clear what your server needs to do.

The server needs also to vend data in (probably) json format (I use Spring MVC + Jackson), so it's responsible for exposing the model to Angular, and communication with the database.

So what's the MVC then on the Angular side?

• Model: The data that comes from the REST API. If the API is vending JSON, then these objects will already be 1st class javascript objects.
• View: HTML, and directives when you need to manipulate the DOM
• Controller: (and custom services that you've factored out of your controllers..)
  • Queries the REST API and puts what's necessary for the View on the $scope
  • Provides callbacks for directives to respond to events that might then require calls back to the server.
  • Validation: usually via a callback to a directive. Will likely overlap some of the validation you've already put in the server, but you don't want your user to wait for the server to validate everything - the client should know something about the validation to give the user immediate feedback.
  • Business logic: Pretty much the same story as validation.

But why the duplication of logic in the client and in the server? Mostly because you're not writing one app, you're writing two independent things:

1. a REST API that needs to be robust and usable without a front end
2. a GUI that needs to give immediate feedback to a user and not necessarily wait for a server.

So, short answer - get the REST API right by forgetting that there will be a UI, and what goes into Angular will be much clearer.

Solution 2:

I think the term "business logic" is a bit of a misnomer here. The "business" of a clientside app is the business of handling the user interface. It's not going to be things like security rules and proprietary logic or other sensitive intellectual property.

So in Angular the division is (generally):

• Controller (controller): for manipulating the data (scope) behind your UI.
• Directives : for setting up the DOM to communicate with the controller via scope, and for manipulating the DOM.
• Templates (view): To assign directives to elements of the DOM.
• Scope (model or viewmodel): for carrying data between all pieces of the system.
• Services : Injectable, reusable bits of code. Usually for dependencies like handling Ajax, cookies, or other I/O.

It's really almost MVVM and not MVC.

As for your "business" logic or rules... anything requiring security must always be secured at the server level.

Solution 3:

It's important to understand that in some versions of the MVC pattern, the data as well as the logic that manipulates the data both reside in the "model" layer (with the "controller" layer doing nothing but binding). In AngularJS, however, the data ($scope) alone resides in the "model" layer, while the logic that manipulates the data ($scope) resides in the "controller" layer.