Is it appropriate to send data from the directive directly to the service?

Question

Angular

For example, instead of giving the result to the controller like this:

<calculate numbers="[5,6]" result=" _переменная_из_$scope_контроллера_ "></calculate>
<concat strings="[ 'hello', 'world' ]" result=" _переменная_из_$scope_контроллера_ "></concat>

leave only the attributes for the input data (here these are numbers and strings), and send the calculated result through $scope.$emit.
Write the handler of this event directly to the service that stores the model for sending data to the server.
Will it be possible in this way to remove the controller as an intermediary between the logic of the directive and the application model? Am I violating the angular-way approach in this way?

Answer 1

Am I violating the angular-way approach in this way?

You are thus violating the MVC approach. Model commands can only be given by the controller. The year is 2015, angular1.5 and angular2 will be released soon, it's time to wean from the heritage of angular1.0 and 1.1
1) no $scope in controllers (read about controllerAs). In fact, the only place where you can use $scope is link directives (which, if possible, are also better not to use). Accordingly, it’s better to use such nice-looking things as $scope.$watch only in link
2) no separate controllers, only directives can have controllers (exceptions are stupid controllers that must map data from state parameters to directive, that is, forward to attributes) . Avoid using module.controller. In general, read about components in the context of angular
3) avoid using pure angular API in your application. Everything with a $ sign (eg $http, $sce, etc) should be wrapped (repository services, filters, separate mini-services...). Thus, we separate the application from the framework as much as possible, and make code support easier (for example, if you want to update dependencies, you won’t have to rewrite the application floor due to some changes in the API, well, I also recommend wrapping third-party libraries in facade wrappers, hiding them from the application (again, for the same reason, surprises are rarely expected with angular, but here are third-party libraries ...).
4) pass the data explicitly, that is, no events, the data should get to the services (your model) by a direct method call from the controller. Then debugging the application and testing it (will you ever start testing applications?) Will not cause pain. Yes, and code support will be greatly simplified. The exception again is when events are emitted and processed somewhere in services, for example when you use web-sockets. Everything seems to be fine here.
Useful materials on the topic:
busypeoples.github.io/post/thinking-in-components-...
teropa.info/blog/2014/10/24/how-ive-improved-my-an...
ps These are just recommendations in case you are not making a prototype on your knee, but a real application. Even if in the near future it will not be realistic for you to practice all this (the application has been sawn for a long time and no one will rewrite it), keep it in mind for the future.
In general, it's up to you how to do what . You then work with this code. Well, or think about the people after you. In general, what you are doing is called writing logic in templates.