Where to put model data and behaviour? [tl; dr; Us

Question

I am working with AngularJS for my latest project. In the documentation and tutorials all model data is put into the controller scope. I understand that is has to be there to be available for the controller and thus within the corresponding views.

However I dont think the model should actually be implemented there. It might be complex and have private attributes for example. Furthermore one might want to reuse it in another context/app. Putting everything into the controller totally breaks MVC pattern.

The same holds true for the behaviour of any model. If I would use DCI architecture and separate behaviour from the data model, I would have to introduce additional objects to hold the behaviour. This would be done by introducing roles and contexts.

DCI == Data Collaboration Interaction

Of course model data and behaviour could be implemented with plain javascript objects or any "class" pattern. But what would be the AngularJS way to do it? Using services?

So it comes down to this question:

How do you implement models decoupled from the controller, following AngularJS best practices?

Answer 1

As stated by other posters, Angular provides no out-of-the-box base class for modeling, but one can usefully provide several functions:

1. Methods for interacting with a RESTful API and creating new objects
2. Establishing relationships between models
3. Validating data before persisting to the backend; also useful for displaying real-time errors
4. Caching and lazy-loading to keep from making wasteful HTTP requests
5. State machine hooks (before/after save, update, create, new, etc)

One library that does all of these things well is ngActiveResource (https://github.com/FacultyCreative/ngActiveResource). Full disclosure--I wrote this library--and I have used it successfully in building several enterprise-scale applications. It's well tested, and provides an API that should be familiar to Rails developers.

My team and I continue to actively develop this library, and I'd love to see more Angular developers contribute to it and battle test it.

Answer 2

An older question, but I think the topic is more relevant than ever given the new direction of Angular 2.0. I would say a best practice is to write code with as few dependencies on a particular framework as possible. Only use the framework specific parts where it adds direct value.

Currently it seems like the Angular service is one of the few concepts that will make it to the next generation of Angular, so it's probably smart to follow the general guideline of moving all logic to services. However, I would argue that you can make decoupled models even without a direct dependency on Angular services. Creating self contained objects with only necessary dependencies and responsibilities is probably the way to go. It also makes life a lot easier when doing automated testing. Single responsibility is a buzz work these days, but it does make a lot of sense!

Here is an example of a patter I consider good for decoupling the object model from the dom.

http://www.syntaxsuccess.com/viewarticle/548ebac8ecdac75c8a09d58e

A key goal is to structure your code in a way that makes it just as easy to use from a unit tests as from a view. If you achieve that you are well positioned to write realistic and useful tests.