Angular 2 gets rid of controllers

In my previous post I talked about the problems of controllers (both at the back-end and the front-end). The issue is that controllers are too general and tend to become full with mixed logic, especially if the page they control has many UI pieces. So instead of having one controller per page, we can have one controller per component and hence decrease the coupling in one’s code.

Some JavaScript libraries, f.x. React, are designed with the component in the center. In Angular 1.x we have the concepts of a controller and a directive. One can attach a controller to any part of the page or when using a router, a controller is automatically assigned to the view. You can easily remove all usages of controllers on your page simply by moving the code into an appropriate directive. Do not forget that you can also rely on the different types of services in Angular for custom logic.

In Angular 2 the notion of controller is completely removed. You should work with directives only and you can actually choose what kind of a directive you want to use for the specific case:

  • Component directives provide a “static” template with some logic behind. It is the same as a directive with a template and an isolated scope in Angular 1.x
  • Template directives work with a user-defined template. It is similar to a directive with transclude in Angular 1.x
  • Decorator directives add extra functionality to an existing DOM element (see Decorator pattern). It is the same as a directive with no translude, no own scope and no template in Angular 1.x

If you think you will miss the mapping to a controller from the router in Angular 2, you can actually do a mapping to a ComponentDirective instead, but I would still opt for slicing your views into smaller components.

From MVC towards components

The nature of HTTP is to provide resources where each resource is identified by a unique URL. A resource can be any kind of file: image, text file, font. Initially web sites used to deliver static HTML pages, which were pretty much limited in terms of content. CGI and server-side scripting languages like PHP, ASP(.NET), and JSP changed this by generating dynamic HTML on the server and sending it back to the client. This allowed the page content to be “configured” by the browser, f.x. using query string. This traditional web architecture is denoted on the diagram below.

Traditional web architecture

It all worked fine until the Web became more complex and developers started to put more and more logic on the server. We ended up having to make requests like /index.php?module=employees&id=5 (especially with some CMS systems). This architecture tended eventually to cause many problems, from search-engine optimization to code maintenance. Continue Reading…

ASP.NET MVC DI with Common Service Locator and NInject

I think everyone knows about Dependency Injection (DI) and how important it is when it comes to building low-coupled components. There are many IoC (Inversion of Control) containers. The most popular are

Each of them has its own pros and cons. I have been using NInject for years and I am really happy with it. Autofac is quite a new DI framework which shows really good results on benchmarks. You can find information for all DI frameworks on their websites or just google them for comparison. Continue Reading…

Test-Driven Development with ASP.NET MVC

ASP.NET MVC has become more and more popular. In my previous post I gave you my vision about it and what it introduced to ASP.NET developers. One of the advantages of the MVC pattern is the better testability. You can easily test every controller without dealing with the View itself.

Test-Driven Development (TDD)

Principles of TDD are really simple. The entire TDD process is described on the following scheme:

Continue Reading…