Where to put the business rule at the angle?

Asked

Viewed 711 times

5

I love programming web and mobile apps with Angularjs. But I’m tired of spreading my business rules by controller and factorys. I miss being able to create my objects with their respective responsibilities, as well as controllers services, as I do in other languages.

How could I have an approach like this, geared towards objects with isolated responsibilities, at the angle? Someone has already implemented it like this?

2 answers

4


If I understood your question correctly (and if my experience can answer it well) I would say that you are not doing it wrong. In Angular, things get kind of "scattered" even, the big question is how well to "organize the mess".

Each of these elements (and there are many of them) has very specific purposes, which are often completely ignored. Whether by poorly elaborated tutorials, the convenience of writing everything in a single place, generating less 'work' or even the lack of knowledge.

Note: In Angular2 this already changes a lot, since it will be much more simplified in this sense.

I particularly develop everything using well say only 3 components of Angular:

  • Controller
  • Factory
  • Directive

Each one has a very simple but very distinct purpose, see:

Factory: Responsible for obtaining data from a backend/api to feed the app with the necessary information.

Controller: Responsible for passing the data (obtained by factory) for the view and also by performing functions called by the user through the UI.

Directive: Conditional HTML manipulation and/or creation of common standard functions in several views - even if the views between them have no relation at all.


In a simple scenario, imagine that you have an E-commerce. As soon as we access, we need to feed the site with the products. For this factory makes the call to backend and obtain the data, storing in a variable still inside the factory.

The controller, in turn, you will seek this information from factory - No matter how it was obtained, it only matters to know that it exists, then passing to the view through a $scope (or vm, depending on the syntax that you use), so we feed the site with the products.

Suppose you want to add a product to the shopping cart, but knowing that the product can be accessed either on the home page, or on the "Bestsellers" page, on the "My list" page, categories, etc.. Note that it is the same function being called from different locations. Therefore, we can apply the function in a directive, so she can be called independent of her view, controller or another component. The cart itself can be managed by a directive also, being that it is accessed from any view.


Although "messy", Angular has components with well-defined tasks and objectives that can keep your application dry, without repetitions and, in a way, well organized. I believe that it should be seen more as a whole than as isolated parts.


Complimentary: A material that, I personally used QUITE and that gave me a very good north in the organization of my code and my components, was this guide: https://github.com/johnpapa/angular-styleguide/blob/master/a1/i18n/pt-BR.md

  • Thanks Celsom, it was very enlightening. I already use John’s style guide and it’s very good too. But I had never looked at Directive with the vision you went through, I was only using for visual components and DOM manipulation. When I needed my own library of functions I created a Factory Utils and there I did my functions. I don’t know if it’s a good approach, but it worked for a while. With your explanation I could use the Directives to play the role of objects with rules that I thought?

  • 1

    In fact the main objective of a Directive is the manipulation of DOM. In addition to the example I quoted above, I have also used it for a purpose similar to the one you commented on. I used to manage login, where the functions were in a Factory and Directive just called them. The same Directive also manipulated the DOM by displaying, hiding or changing menus and other objects according to the user’s level or if it was not even online.

-2

Overview and Concept, official Angular

View independent business logic: Mounts in Services

When the application grows, it is good practice to move the controller’s independent display logic to a service, so that it can be reused by other parts of the application as well.

The advantage of working with Angular is component assembly, so you can change your business rule in the service and the front end continue presenting the data without the need for adjustments in both the View and the controller.

Browser other questions tagged

You are not signed in. Login or sign up in order to post.