I am implementing a functionality for (Add,update,delete & get,filter).
Currently Add View is used for add, update and delete. (Controller1)
Get View is used for get and filters. (Controller2)
Created routing for Add and Get Separately. So 2 controllers for each.
Now i have to call service for common config data , which is used in both the controllers.
which of the below design i should prefer.
Design 1
Combine both the controllers a one controller, put all the code inside.(including config data)
Design 2
One controller for Get ,filter
Second controller for Add, update and delete
common factory for Config data.
Am confused, which design i should prefer from all the aspects.
Please suggest.
Thanks in advance.
Its good practise to have "skinny controllers"
EDIT -
In AngularJS, controllers can sometimes become monolithic structures of mixed business and view logic, as it’s all too easy to house anything you need for the view inside the controller. It’s convenient, and it just plain works… until your application grows in complexity or needs unit tests.
So why do we want skinny controllers, anyway? In short, separation of concerns. Ideally, everything from services, to controllers, to directives, and more should be skinny, and achieving this is very possible in AngularJS. Each part should have a single responsibility and the controller’s responsibility should be to communicate between services and the view; i.e. its main concern should be view-model logic.
Aim to make your controllers skinny, as well as the rest of your application, by separating out view logic and business logic into controllers and services, respectively, and by taking advantage of routes and resolves.
You can read up in detail in this article & look at code examples
Related
I'm new to AngularJS and i'm wondering what's a good way to visualize a AngularJS app (with UML classdiagram/componentdiagram)? And the reason why.
Can you give a example?
I found this, but don't know if this is a right way: https://hacks.mozilla.org/2014/11/visually-representing-angular-applications/
Thank you
You can use a Class Diagram to represent your Controllers, Factories, Services, etc (as show in the link provided by M22an in comments). In this diagram, you can easily show the methods and attributes of each Controller / Service / Factory.
You can use a Sequence Diagram to represent the communication between the parts of your app. Show each method, show which part of a service it calls, the data given and received, the update of the template with the $apply method etc.
A component diagram can be useful to explicit the content of each module and show the Controllers / Services / Factories... inside it. You can show the modules dependencies using this diagram too.
In my opinion, you can use almost all diagrams you want, AngularJS is huge, powerful and complex, and each UML diagram will be useful to represent a part of his behavior.
I always wonder
How Sencha Touch 2 knows which controller to run first and which one is the next
How does ST2 knows which controller is in charge of which view.
Can we have more than one controller on one view, if yes, how to wire them up?
Can we have more than one views controlled by one controller? if yes, how does the events flow?
How to wire up view1 with controller1,......, viewX with controllerX.
Thank you.
Re.: 1 - Controllers are initialized, if you mean that by "run", in the order they are listed in application controllers:[] array. See also ext application startup sequence:
Re.: 2 - Controllers just listen to events that come from views. The listeners are installed in init method of controller
Re.: 3 technically yes - more than one controller can listen to events of same view - but it is not a good practice. It's like to have more bosses
Re.: 4 yes and it is ver common that one controllers controls more than one view
Re.: 5 see application architecture
My answer refers to Sencha Touch 2.3.1.
There is no real "coupling", except the relations you define through refs and control property of the controllers http://docs.sencha.com/touch/2.3.1/#!/api/Ext.app.Controller.
All of the Controllers that an Application uses are specified in the Application's Ext.app.Application.controllers config. The Application automatically instantiates each Controller and keeps references to each
I guess the order in which the controllers are included is defined by the controllers property of app.js (it would be pretty easy to verify anyway by putting some console.log() in the init method of each controller).
There is no such a relation of "being in charge" for a View, controllers have references to Views, that is all. It's worth mentioning that controllers may require views (and stores and models) but that is just related to inclusion in the packaging phase, there are no "bindings" to those components at runtime.
It's possible, just define two controllers that have both a reference to the same view. That would be bad anyway, because it would spread the logic for the same view in multiple places.
Yes it's possible. For example I use to write a single controller to manage set of simple views always used together (for example a wizard). You simply have all the handlers for the events of those views in a single controller.
The encouraged way is through through refs and control property of the controller http://docs.sencha.com/touch/2.3.1/#!/api/Ext.app.Controller.
In summary, in my opinion, controllers are more a tool for the developer to organize code meaningfully and to improve maintainability, rather than a rigid implementation of MVC in the framework.
I've noticed some people define a new module for each controller, service, directive etc.
angular.module('controllers.Dashboard',[]).controller(...);
angular.module('controllers.Details',[]).controller(...);
angular.module('controllers.List',[]).controller(...);
However, isn't that a performance issue? I mean: for each controller you create, you also create a new module.
What do you think?
Any performance hit would be incredibly minimal. What you do gain in terms of performance though, is testing speed. Testing can be localized to small modules that don't need to load in the entire application to perform what they need to.
On the code organization side, I personally like the idea of breaking up modules depending on feature not architectural slice. So instead of having a module for controllers, a module for services, etc, create a new module for every new feature/piece of the application. This way you can group together conceptually related controllers, views, services, filters, and so on.
The overhead will be minimal in practice. It is really more of a code organization type issue. On my project we have a FooService, FooController,FooDirectives, BarService...
I've written a helper to help with generating URLs in my CakePHP 2.3 app. Basically it's a wrapper around Cake's built-in functionality, that helps handle routing prefixes, avoids key/value array pairs for common things, etc, to make the code a bit tidier.
The problem is, I need basically all the same functionality for easily generating these URLs from my helper, available in my controllers - for things like loginRedirect, redirecting after edits, etc.
Is there a good solution for sharing logic between Controllers and Views without duplicating code? I understand that in general Views and Controllers shouldn't share code - but there are exceptions.
You can create a 'Utility' and create 'Helper' and 'Component' wrappers for that, that can be used inside your Controller and Views, something like the TextHelper / String Utility combination.
So, I'm in the midst of my first major project with Angular. I have one controller that is doing a ton of the legwork, and it's reached the point where it's thousands of lines of JavaScript.
I'd like to break this up somehow, but I can't seem to find a solid example anywhere. The code is mostly made up of functions used to do calculations on objects, so directives and modules don't seem like the right answer, but I could be wrong there.
How are you guys organizing code in your large Angular projects? Should I just suck it up, or is there a sane way to split this into easy to scan files?
I suggest putting at least some of those objects and their related calculations into services, then inject the services into your controller(s). See the Sticky Notes Part 1 blog entry for an example of a service that encapsulates some data and provides methods to access/manipulate that data.
See if you can break up your controller into multiple controllers, one for each view. A view can be as large as a page, or just some chunk/block on a page.
To quote from a google group post I saw recently: "I prefer to think of angular controllers as dumb apis/configs for my views and leave all the heavy lifting to services." -- reference
There are a few things that you need to ask yourself when you are in a controller.
Are you doing any DOM manipulation in the controller? This is a definite NO. Dont ever do that. It always belongs in the directives department.
Are you writing any Business Logic in your controller? That too is a NO. Your Business logic should in most cases exist in a Service. That is the right place for it.
Now, have a look at your controller. Is it devoid of these 2 things and still larger than 1000 lines? It is highly unlikely, but even if it somehow is happening, then consider breaking down your controller into smaller controllers. This breaking of controllers have to be done based on the view.
To sum things up, your controller is just a place where you glue up the business logic and your views in the HTML. It should technically never contain anything other than these glues.
I usually create a Util factory (seems to be the way to go now in Angular rather than services) and have it return any shared logic as a set of methods.
https://gist.github.com/lamba/c275f5f010090632209e