Why do we need services or factories, we can also do the same thing by making a normal javascript function, or writing the logic in the controller itself.
For example, when i get json data from the server using '$http.get', i can do it by writing a separate service for it but why is it even required when we can directly write its code in the controller?
This is a good question to ask for clarification before digging into Angular as understanding the parts will enable you to write good Angular code and not just do something because you can.
http://i.stack.imgur.com/BKl1Y.jpg
This is a good visual for Angular as an MVC.
The simple answer to your question is that services should be passing information through your controllers to your various pages and routes. All information logic shared across these views belongs in the service. Controllers pass along that information from the view to the service and from it. Information and logic local that view that doesn't need a broader scope can stay in the controller. This is the clean separation that makes Angular a strong framework.
Related
I am developing an angular web game where I have a bunch of quests that use a single html template for the view. The problem I have is how to organize the Angular code.
Should I have only one controller (which will hold the non-quest-specific logic) and uses a bunch of services (one for each quest-specific logic)? The controller would probably have a big if/else block to use the right service for the chosen quest.
Or should I have one controller for each quest? That way we can use fewer services overall and share them among the various controllers for the quests.
Which one makes more sense and would potentially have the fewest code duplication? Could there be a better alternative to both?
I just suggest you to go for a controller per unit and build the services thinking as elements that you can share between controllers structuring them as functional independent shareable elements.
Quest 1 = controller 1 -> inject all services needed for that quest
Quest 2 = controller 2 -> inject all services needed for this one
.......
You can't share code between controllers. If you want to have less duplicated code you should create services so you can share code between them and the controllers.
A good description of angular controllers vs. angular services can be found in an earlier post
I would recommend using a controller for each quest. Inject services into each controller that are relevant to that particular quest. Although you'll still need to write services to share that data/logic with the controller, you can avoid the unnecessary service injections as well as that massive if/esle block
I create a project structure of a web-app with angular.
I create my directories with services, controllers and views.
Then, my team ask me: where are the models? (Nobody of us have worked with angular)
And I answered that in the service, because is where the data persist.
But Im no really sure, and I cant find useful info about this.
What you are looking for is a factory provider. You can create a factory with a collection inside, and this "class" has operations to handle the collection and sincronize it with the back-end.
See this example:
https://github.com/AngularClass/angular-websocket/blob/master/README.md
You can see how to create a collection and initialize it with data that comes from a websocket.
Aditionally you can create operations to handle the collection
This could be consider a "model" in angular.
It is a best practice to keep business logic in Services (and not in controllers, for example). This is, among other reasons, because controllers are instantiated for each view and Services are singeltons.
You can refer to those great posts for more details:
https://johnpapa.net/sharing-data-in-an-angular-controller-or-an-angular-service/
http://teropa.info/blog/2014/10/24/how-ive-improved-my-angular-apps-by-banning-ng-controller.html
https://toddmotto.com/rethinking-angular-js-controllers/
I'm going to assume from the verbiage you've used that you're referring to Angular 1.x.
Services are typically used by controllers to pull data from a provider not displayed in the view. The provider can be a public api, a static file on your own server, a mongo database, etc.
A model for a controller represents the data being manipulated between the view and the controller (refer to ngModel).
In a recent project, we opted for johnpapa angularjs framework for a web app. Now, we want our pages to interact with web api located on the server. So, for this I have googled a bit and found that there are two approaches one is factory and other is service. And the datacontext located in johnpapa angularjs framework is a factory. So, now it looks like that all the calls we going to make to our webapi's needs to be implemented in teh datacontext factory. Which seems little messy imo. And what I want is to create a seperate file for each service/factory i.e. userSvc.js, orderSvc.js
So, is it a good approach to split the functions in different service/factory according to their logical separation. And, second thing is that do i need to create service or factory for calling webapis.
As a backend developer I am little bit struggling with Angular UI MVC concept.
I am trying to draw parallels to my backend MVC so I can understand mindset behind Angular better.
On my backend I have services talking to repositories(or DAOs (Data Access Objects) how we called them in past), controllers calling services to do the job(as they only transport data and not do heavy lifting) and talk to the client(ie browser) and my Model is a combo of(DTOs (Data Transfer Objects) and Entities as of ORM).
As I am inherently inspired by having backend only ever to return/accept JSON(big no to JSP,FreeMarker,Velocity and all others which make my testing life so hard). I would say that on my backend I only have Model-Controller. From the backend perspective my View is AngularJS as JSON data I return could be labelled as part of my Model but it is definitely not my View.
Now when I start to think about UI MVC as of AngularJS I don't understand who should use $http service to talk to backend. The endless examples scattered across the web do not help me. They are either too minimalist or don't show the usage of $http in the full context(simply called from controllers).
I could argue easily for both.
Case A: If AngularJS treats backend as Model then it is the responsibility of angular's services to call $http to talk to backend to retrieve/post data. Here angular controllers still act as basic transport between View and Model ocassionally calling services to get and process data from backend.
Case B
I could also say, hold on - "no", if angular's controllers role is solely to transport then they should get data from backend and deliver to required destination i.e. angular's service/view(if no further processing required).
So which one is "right"? Or at least widely accepted by UI/fullstack devs?
Controllers should only be connecting data and logic with the view and in the most minimal way possible. A bulky controller suggests that either the view needs to be divided up or logic needs to be abstracted into services. $http calls definitely belong in services. The controller doesn't care how the data comes, just that it comes. So:
// controller doesn't care how
getData().then(function(data) {
VS:
// controller is too concerned with "how"
$http.get('/the/path').then(function(data) {
It is typical to see $http calls in controllers in sample code, but not in professional production code.
I would strongly suggest Case A: having this in a service.
Think of Angular controllers as owning each specific piece of view they are assigned to, with services providing ready-made functionality for those controllers.
Also note that a single page can have many views, each of which could be bound to its own instance of a given controller. So it doesn't really make sense to have $http-based functions etc being instantiated a bunch of times. For a service, it will be instantiated once and then shared across any controller that injects it. This is also a great way to share data between controllers, and is one of the strongest reasons to use a service for any given task.
One other suggestion is that thinking of Angular as MVC can lead to issues. Angular is flexible enough to follow multiple design patterns, hence the MVW (Model View Whatever) moniker, but the majority of applications I have seen tend to follow the MVVM pattern. For this reason I would say that the controller should never have knowledge of $http in most cases.
I started working with AngularJs recently.
Looking to understand the reason for using multiple controller, I found different site explaning how to use multiple controller (AngularJS site). But what I'm actually looking for is a rationnal for using multiple controller.
So my question is : Why or when should we use multiple controller in a project? and the subquestion that is tied to this question: is it a good pratice to use multiple controller in an Angular project.
That's also an MVC question as angular extends this pattern. In Apple's View Controller Programming Guide for iOS, it says :
Every view is controlled by only one view controller.
So the idea in MVC pattern is to separate views. By having 1 Controller per View it makes it easier to achieve this. it simplifies the organization of controllers that serve one module. You do not suffer from code smells.
Also, it is important for routing issues in app.js for angular case. It clarifies structure for other developers that will have look at project. Using testacular in angularjs, unit testing is great, having multiple controllers makes unit testing easier.
Edit :
You would also most likely need more controllers for further functionalities. For example a Auth Controller where users can create new accounts. In addition to this you need a superadmin view where you can edit the resources with higher privileges. In such a case it is quite common to have separate controller. Scope and security issues has to change.
It is just a very good pratice to use 1 controller per 1 view. So for example you should have seperate controller for /home view, another one for /gallery, and another /contact.
It forces you as a developer to organise your code, so that you can take advantage of using services, filters etc.
Also it is easier to write unit tests because you can see what is covered and what is not.