This session went into some of the patterns you see out there. A quick summary:

• Services: these are injected singletons. They’re an ideal place to cache application-level data, as a facade for the browser and third-party API’s, or factories for instantiating other objects.

• Databinding: this is just an implementation of the observer pattern.

• Inheritance for services & controllers: Standard prototypal inheritance can be used with services and controllers, but it’s recommended to avoid inheritance for page controllers.

• Thick models: for example, instead of having a method isActive(item) on the controller, put the isActive method on the item itself. Prefer thick models with methods and behavior over having this in your controllers. This way, you can encapsulate your domain logic.

• Directive proxy object: how can you communicate with a directive from a controller? We want to avoid coupling the directive tightly to the controller. With this pattern, the controller creates and owns a proxy. It doesn’t need to know the directive. The directive can then bind to the proxy object.

• Polymorphism and directives: move responsibilities that normally are in the directive to the model. The model can be switched for another, as long as it has the same interface.Then some anti-patterns:

• War & Peace controllers: very large controllers that do too much. Split it up in more controllers, services,…

• Link Function of Doom: all code of a directive in its link function

• Forgot About Dialogs Global state: services storing per page state and clearing upon route change. This is not what services are for.

• Magical Prototype Chain Dependency: relying on properties up the chain, making refactorings/changes harder/more scary.Don’t ask yourself if it’s "the Angular way". Ask yourself if it’s good software (refactorable, testable, readable,…).