I have worked with MVC on the back-end (Rails), and am currently working with MVC(MV*) on the front-end (Angular). I have seen Angular as considered an MV* pattern, but why is it considered that exactly?
Using Angular, I understand the separation of concerns, with Views (templates), Controllers, and use Services to serve up data. In this case, the model (data store) via ng-model makes sense for front-end temporary storage, but the actual persistence (when a POST or PUT is made to an API) seems to be the wildcard. As the way data can be persisted, could be handled differently (database, firebase, etc..).
It seems to me that *VC is more appropriate based on my understanding, as Controllers in Angular are better defined than Models.
There must be something core about the MV* pattern that I am missing or confused about, any clarification is greatly appreciated.
Here are a few ways * can be chosen in Angular:
Controller:
ngModelController
$controller
View Model:
dependent expressions
directive attributes
Presenter:
WebGL Directive
Presentation-Abstraction-Controller
module per iframe
Important thing is that UI and Models are the common denominator. Build interesting UI without breaking app and build interesting business logic without breaking UI.
References
Keynote for BackboneConf with Jeremy Ashkenas
Related
In the AngularJS documentation: https://docs.angularjs.org/guide/controller it says:
Controllers should contain only business logic. Putting any presentation logic into Controllers significantly affects its testability. Angular has databinding for most cases and directives to encapsulate manual DOM manipulation.
Now, in the book I'm reading (AngularJS Up and Running O'Reily), which is a highly recommended book for learning AngularJS, it says (on page 17):
Some of the more common responsibilities of a controller in an AngularJS application include:
Presentation logic, such as how to display elements, which parts of the UI to show, how to style them, etc.
Isn't this exactly what the documentation not to use controllers for? What's recommended? (is it recommended that the controller handles the business or the presentation logic?).
Both can be handled using Angular JS, presentation layer and business logic layer. Suppose you have to point any action to UI with respect to run time changes that would be checked - business logic layer.
Suppose I have to upload a image/file now using angular's module I'll take the image/file and then it'll be sent for upload to server - let's say node js server- now angular can receive timely updates about upload progress and that would be shown on the presentation layer.
If you need more clarification please let me know.
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.
So I am just starting out with angularjs and web development in general and had a few questions regarding the best practices. Some of my questions are actually more related to web development in general.
1) When to use partials and when to use a different page instead. E.g Is is good to embed about.html as a partial in index.html or have a separate page?
2) What is the best way to share data between controllers? Right now I am using query parameters in the route.
3) Should I be using one controller for multiple partials?
Thanks!
Angular is a single page app framework, so you only want to use one html 'page' in most cases. There may be exceptions but unless your project is very large you won't need to use more than one.
Services are the recommended way of doing this. Services return a singleton object, and you can inject references to them using angular's dependency injection. It keeps everything modular, too. Query params are definitely not what you want to use. For calling events between controllers you might also use $scope.$broadcast().
Potentially, you might have an overall AppController for example that encompasses elements that have their own controllers (in their own directives, or using ng-controller). On the subject of directives, remember to use them to bundle re-usable components up. Directives have their own templates and controllers, and using them makes your code much more modular and easier to maintain/test.
I am learning AngularJS and MeteorJS and would like to use them both. I noticed that each package has their own object to store global variables: $scope in Angular, and Session in MeteorJS.
Does it make sense to sync them, i.e., a variable change in $scope will cause corresponding change in Session and vise versa? How should I go about it?
(Not an entirely satisfying answer but rather a quick heads-up as I'm currently experimenting/evaluating with both right now)
Meteor uses the Session as a global cache object whereas Angular $scope is simply but powerfully based on the classic concept of scopes -- and along the way brings an intuitive understanding of what it means. In other words, controllers and directives in Angular have their own $scope, while Meteor templates and pretty much all objects could all access the Session object.
As far as I see the current benchmarking game between Angular and Meteor, both are very well thought frameworks but don't fit too well together as many components are redundant -- same observation for Backbone and Meteor. Reactive programming is achieved in Meteor, same as Angular does it with the two-way binding variables. Meteor seems to make things easier by enabling one language and toolbox for both client and server.