I agree. In the case that you have 10 different model items (a complex page), 10 mutation wrapper functions all merged into 1 controller is a mess. This is assuming that your page does more than count. The controller functions should represent your view, and allow the views interactions, eg. clicks, to properly map to your models. In this way, #2 is good. I wouldn't however be scared of directly revealing model objects.
Think a User object. If you have 'name', 'status', 'bio', etc. all on an api and revealed my a service. Will you write getters/setters for each value in the controller? Id say no. But if the age needed to say, query users, then you need to build the button that clicks 'query' that might map to calling methods on a userManager which then refreshes an array of results of user objects. The handling of the query request and management and mutation of a local dataset might be in the controller for example. On 12 August 2014 03:02, Mark Volkmann <[email protected]> wrote: > I agree with keeping controllers skinny, but in approach #1 the > controllers do nothing. That's an extreme version of skinny. > > > --- > R. Mark Volkmann > Object Computing, Inc. > > On Aug 12, 2014, at 2:08 AM, Tony pee <[email protected]> wrote: > > I'd go for method 1. Im a fan of less code, either way, you are looking to > mutate the model, and have setup the api on the model (service) for doing > so. To me, the controller is a 'view model' comprised of many model > objects, of which your service is providing one. Therefore, i'd feel free > to expose it. More code (wrappers) just means more maintenance. I like to > move as much code OUT of the controller as possible, fat model, skinny > controlller you may have heard of. Controllers are just glue. > > > On 11 August 2014 19:29, Mark Volkmann <[email protected]> wrote: > >> In my opinion, only controllers should modify the scope. For that reason, >> only method 2 makes sense. Controllers should call service methods to run >> business logic and make REST calls. If anything needs to be assigned to a >> scope property, service methods should return it to controller functions >> and those should modify the scope. >> >> --- >> R. Mark Volkmann >> Object Computing, Inc. >> >> On Aug 11, 2014, at 8:57 PM, Colin Kahn <[email protected]> wrote: >> >> There's quite a bit out there about using controllers and services >> together, and was hoping to start a discussion to try and nail down some >> best practices. >> >> There's three different methods i've seen for using controllers and >> services together. They all assume (I believe) that you're holding the >> state in your services, and your controllers are stateless. >> >> Method 1: Expose Service to Template >> >> This one is probably the simplest. You treat your service like a model >> and you put it on scope (or on your controller and your controller on scope >> using the "as" syntax) and then in your templates access its properties and >> methods. >> >> app.service('serviceCounter', function() { >> this.count = 0; >> this.increment = function () { >> this.count++; >> }; >> }) >> .controller('ServiceCounterController', function (serviceCounter) { >> this.serviceCounter = serviceCounter >> }); >> >> <div ng-controller="ServiceCounterController as serviceCounterCtrl"> >> {{serviceCounterCtrl.serviceCounter.count}} >> <button ng-click="serviceCounterCtrl.serviceCounter.increment()">Add >> One</button> >> </div> >> >> Method 2: Wrap Methods in Controller >> >> For this, you create a specific API in your controller that uses methods >> from your service: >> >> app.service('serviceCounter', function() { >> this.count = 0; >> this.increment = function () { >> this.count++; >> }; >> }) >> .controller('ServiceCounterController', function (serviceCounter) { >> this.getCount = function () { >> return serviceCounter.count; >> }; >> this.addOne = function () { >> serviceCounter.increment(); >> }; >> }); >> >> <div ng-controller="ServiceCounterController as serviceCounterCtrl"> >> {{serviceCounterCtrl.getCount()}} >> <button ng-click="serviceCounterCtrl.addOne()">Add One</button> >> </div> >> >> Method 3: Reassign Service Methods to Controller >> >> Here, you would reassign your methods onto the controller: >> >> app.service('serviceCounter', function() { >> var count = 0; >> this.increment = function () { >> count++; >> }; >> this.getCount = function () { >> return count; >> }; >> }) >> .controller('ServiceCounterController', function (serviceCounter) { >> this.getCount = serviceCounter.getCount; >> this.addOne = serviceCounter.increment; >> }); >> >> <div ng-controller="ServiceCounterController as serviceCounterCtrl"> >> {{serviceCounterCtrl.getCount()}} >> <button ng-click="serviceCounterCtrl.addOne()">Add One</button> >> </div> >> >> Obviously if someone has better examples of any of these please share. >> >> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - >> >> My pros and cons list is as follows: >> >> *Method 1: Expose Service to Template* >> >> *Pro:* >> >> - Simple, very obvious where you're accessing the properties and methods >> - Able to bind to the services properties without needing a $watch in >> your controller or using events >> >> *Cons:* >> >> - Verbose, your template expressions become very long due to the >> repetition of the name >> - Service is coupled with templates, changes to how the service works >> could break your UI >> >> >> *Method 2: Wrap Methods in Controller* >> >> *Pro:* >> >> - Still obvious where methods and properties come from (everything goes >> through the controller) >> - Service is not coupled with the templates, if the service changes your >> controller methods can be updated without touching the templates >> >> *Cons:* >> >> - Verbose, everything needs to be wrapped >> - Properties must be accessed through methods, increasing function calls >> during each watch cycle >> >> * Method 3: Reassign Service Methods to Controller* >> >> *Pros:* >> >> - Less verbose than method 2, while keeping some separation between the >> service and the template >> - Service acts more like a module with private state >> >> *Cons:* >> >> - Could be unclear how things are being updated since `this` is actually >> the `this` of the controller >> - Still can't bind directly to properties, state must be wrapped in >> functions >> >> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - >> >> If you've got any insight, or have tried these methods to success please >> post. Also, if I've left any ways of doing this out I can update this post. >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "AngularJS" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To post to this group, send email to [email protected]. >> Visit this group at http://groups.google.com/group/angular. >> For more options, visit https://groups.google.com/d/optout. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "AngularJS" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To post to this group, send email to [email protected]. >> Visit this group at http://groups.google.com/group/angular. >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > Tony Polinelli > > -- > You received this message because you are subscribed to the Google Groups > "AngularJS" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/angular. > For more options, visit https://groups.google.com/d/optout. > > -- > You received this message because you are subscribed to the Google Groups > "AngularJS" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/angular. > For more options, visit https://groups.google.com/d/optout. > -- Tony Polinelli -- You received this message because you are subscribed to the Google Groups "AngularJS" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/angular. For more options, visit https://groups.google.com/d/optout.
