• But my questions really aims at “where to put the model objects in angularjs”.
  • service(‘Job’, [‘Restangular’, function(Restangular) { var Job = Restangular.service(‘jobs’); Restangular.extendModel(‘jobs’, function(model) { model.getResult = function() { if (this.status == ‘complete’) { if (this.passed === null) return “Finished”; else if (this.passed === true) return “Pass”; else if (this.passed === false) return “Fail”; } else return “Running”; }; return model; }); return Job; }]);
  • model/Element.js (using angularjs Factory, made for object creation)
  • There are no classes to inherit from or special accessor methods for accessing or changing the model.
  • Resource objects are basically the models in Angular.js..

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.

@JavascriptQnA: Where to put model data and behaviour? #javascript #model-view-controller #angularjs #dci

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.

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?

I’m currently trying this pattern, which, although not DCI, provides a classical service / model decoupling (with services for talking to web services (aka model CRUD), and model defining the object properties and methods).

Note that i only use this pattern whenever the model object needs methods working on its own properties, that i’ll probably use everywhere (such as improved getter/setters). I’m not advocating doing this for every service systematically.

EDIT: I used to think this pattern would go against the “Angular model is plain old javascript object” mantra, but it seems to me now that this pattern is perfectly fine.

EDIT (2): To be even clearer, I use a Model class only to factor simple getters / setters (e.g. : to be used in view templates). For big business logic, i recommend using separate service(s) that “know” about the model, but are kept separated from them, and only include business logic. Call it a “business expert” service layer if you want

DCI is a paradigm and as such there’s no angularJS way of doing it, either the language support DCI or it doesn’t. JS support DCI rather well if you are willing to use source transformation and with some drawbacks if you are not. Again DCI has no more to do with dependency injection than say a C# class has and is definitely not a service either. So the best way to do DCI with angulusJS is to do DCI the JS way, which is pretty close to how DCI is formulated in the first place. Unless you do source transformation, you will not be able to do it fully since the role methods will be part of the object even outside the context but that’s generally the problem with method injection based DCI. If you look at the authoritative site for DCI you could have a look at the ruby implementations they also use method injection or you could have a look at here for more information on DCI. It’s mostly with RUby examples but the DCI stuff is agnostic to that. One of the keys to DCI is that what the system does is separated from what the system is. So the data object are pretty dumb but once bound to a role in a context role methods make certain behaviour available. A role is simply an identifier, nothing more, an when accessing an object through that identifier then role methods are available. There’s no role object/class. With method injection the scoping of role methods is not exactly as described but close. An example of a context in JS could be

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!


You might also like More from author

Comments are closed, but trackbacks and pingbacks are open.