Controllers

AngularJS follows the Model-View-Controller (MVC) micro-architectural pattern. Some may argue that it looks more like Model-View-ViewModel (MVVM) because of the view model attached as properties to the scope or the current context in case of controller as syntax. It could be approached differently again, if we use the Model-View-Presenter (MVP). Because of all the different variations of how we can structure the logic in our applications, the core team called AngularJS a Model-View-Whatever (MVW) framework.

The view in any AngularJS application is supposed to be a composition of directives. The directives collaborate together in order to deliver fully functional user interfaces. Services are responsible for encapsulating the business logic of the applications. This is the place where we should put the communication with RESTful services through HTTP, real-time communication with WebSockets, and even WebRTC. Services are the building blocks where we should implement the domain models and business rules of our applications. There's one more component, which is mostly responsible for handling user input and delegating the execution to the services: the controller.

Although the services and directives have well-defined roles, we can often see the anti-pattern of the Massive View Controller, which is common in iOS applications. Occasionally, developers are tempted to access or even manipulate the DOM directly from their controllers. Initially, this happens while you want to achieve something simple, such as changing the size of an element, or quick and dirty changing styles of elements. Another noticeable antipattern is the duplication of the business logic across controllers. Often, developers tend to copy and paste logic, which should be encapsulated inside services.

The best practices for building AngularJS applications state that the controllers should not manipulate the DOM at all; instead, all DOM access and manipulations should be isolated in directives. If we have some repetitive logic between controllers, most likely we want to encapsulate it into a service and inject this service with the dependency injection mechanism of Angular in all the controllers that need that functionality.

This is where we're coming from in AngularJS. All this said, it seems that the functionality of controllers could be moved into the controllers of the directive. Since directives support the dependency injection API, after receiving the user's input, we can directly delegate the execution to a specific service, already injected. This is the main reason why Angular now uses a different approach, by removing the ability to put controllers everywhere using the ng-controller directive. We'll take a look at how the responsibilities of AngularJS controllers could be taken from the new components and directives in Chapter 5, Getting Started with Angular Components and Directives.