According to my knowledge angular follows mvc architecture as i can see in the components there is .ts file(model) and .html file(view) but where is the controller?
While using the Angular framework, it is necessary to understand a few basic terms which will constitue the application you create.
Component: A component is a resuable code, which is capable of performing a set of functions or providing a view based on certain inputs. These inputs are optional. The component may additionally emit events in order to inform its parent component of the changes which might have taken place due to a particular action such as a click.
I am not too Keen on using MVC notation but if we were to strictly choose,
the template would represent the View, class is the Controller & the Service (when it used to retrieve data) is the model.
Because Angular is a client side framework, the MVC pattern Angular follows may be called as MVVC (Model, View, View Controller).
There is no such thing controller in angular.
It's only have component, view, model, services
Component: Will play the role of the controller since it handle
logic for the template
Template: Will handle the role view to display the data
Model: Entity model will play the role model in your app
Services: To handle logic for you making http request or doing some side effect in your code
.ts is just the file extension which represents typescript file.
model-name.model.ts is the the common way of naming model. Similarly, component-name.component.ts is for component, component-name.component.html for view and service-name.service.ts for service.
Finally, as the earlier comment says, you can't directly relate MVC with angular architecture.
Related
i'm very confuse about how ember controller works.
I'm starting with ember and ember-cli now, and i would like to understand more about how controller works.
If i have an nested route called new, inside a events resource, i should i have:
models/event
routes/events/new
templates/events/new
What about controllers?? I just work one simple controller, or should i use controllers/events/new too?
There isn't any generator command that will create every resource for me? I need call one by one?
Thanks.
What about controllers?? I just work one simple controller, or should i use controllers/events/new too?
This mainly depends on what is your controller needs to do. If it's only the essential stuff the controller does anyways, Ember will create that controller under the hood for you and automatically bubble actions up to its parent controller.
No better place than Ember guides to read what a controller is used for:
The simplest definition is:
Controllers allow you to decorate your models with display logic.
This means that you basically use them as the main communication layer between your route and your template. Essentially, you model comes from your route, through your controller and into your template. Actions happening in the template go up to the controller and then to the route. Therefore, controller is essentially the middle layer where you user your model (and other data) to control what is shown to the user, control what a user can do, control where can they navigate etc.
However, be aware of the plan for the future:
Controllers are very much like components, so much so that in future versions of Ember, controllers will be replaced entirely with components. At the moment, components cannot be routed to, but when this changes, it will be recommended to replace all controllers with components.
This means, that right now, controller responsibility is limited to two things:
Maintaining application state based on the current route
Handling or bubbling user actions that pass through the controller layer when moving from a component to a route.
All actions triggered on a template are first looked up on the controller, if it is not handled or bubbled (by return true) in the controller, they are looked up on the route.
Therefore, controllers for your /events or events/new routes aren't necessary at all, only if you want to handle things happening on those routes right away (in a smaller scope) instead of allowing everything to bubble up to the ApplicationController.
There isn't any generator command that will create every resource for me? I need call one by one?
Yes. Since, if you don't specifically create a controller, Ember just generates one for you behind the scenes. You need to specify where you want to handle things yourself.
You should visit the link I gave above (or here it is again) to the Ember guides that have many more examples in much more detail.
I come from a Backbone / Marionette background and have been working in React for a few weeks now. A lot of people say you should pair React with something like Backbone or Ampersand.js, using React as the V and Backbone / Ampersand as the "M" and "C" in the classic MVC model.
However, the more I think about this, the more I wonder if it's really necessary. In Backbone / Ampersand, the model's main purpose is to track state, and "tell" views to update when the model's state changes. Of course in React, the view takes care of this responsibility via the view's props and state, which seems to make a full blown Backbone / Ampersand model unnecessary and duplicative.
What am I missing?
First, let's define model in MVC terms. The following is from Wikipedia.
[...] the model, captures the behavior of the application [...] independent of the user interface.
The model directly manages the data, logic and rules of the application. A view can be any output representation of information [...] multiple views of the same information are possible [...].
The third part, the controller, accepts input and converts it to commands for the model or view.
In React you inevitably will create View+Controller components; much like angular, knockout, and most other JS application frameworks.
Why models?
While you could also throw the model into the component at this level, it turns out to not work well in practice. You have problems like overfetching (and other optimization limitations), difficulty testing, no separation of concerns, and it's difficult to see what the component actually is until you mentally separate the controller behavior from the model behavior.
So, backbone?
If you have this code, and you want to make it better, you'll eventually end up with models. It could be backbone models, or it could be flux stores, or it could just be simple objects with functions that call $.ajax.
It makes little difference what kind of models you use, but you do need them.
MODEL ALL THE THINGS
Woah! Hold on there. Models aren't free. Every time you use a model you're crossing the abstraction boundary, and leaving component land. It's an imperative action in a declarative system, so we need to keep things predictable.
Most of your components are pretty dumb. Props, and maybe some UI state. You have controller components ("View Controllers"), which are 100% tied to your model layer, and you have the rest of the components which are (ideally) 0% tied to your model layer.
What you seem to be describing in the original question is a small application where you have one of these controller components. However as these grow, you need to coordinate between them (not fetching the same user twice, for example). You nest these controllers inside other controllers to build an application. The model is the glue.
You can think of a React component as a functionally pure function that takes props and state as input arguments. Its render() method's job is to produce and returns a (virtual) DOM element or JSX (syntactic sugar) based on props and state. Backbone still "owns" the model. When the Backbone model changes via user inputs or socket events or whatever, setState() can be called (add some magic here) which causes React components to render again. The point is React component does not hold the state. This is NOT to say that one must uses Backbone with React as React is simply a rendering library.
Update: In react-future, it's very clear that render() should be treated as a pure function. It takes props and state as input arguments and its job is to produce a JXS, so no need to refer to the this keyword.
https://github.com/reactjs/react-future/blob/master/01%20-%20Core/01%20-%20Classes.js
Let's say we are implementing CRUD operations for a specific object - those view would be very similiar and i think i should use the same view with multiple controllers. Is there a way to choose the controller dinamicaly based on a parameter or this type of action can be only taken inside the controller?
You technically can, but according to the exellent angular styleguide from Johnpapa, style Y037 :
Define a controller for a view, and try not to reuse the controller
for other views.
Though, you're actually right thinking that some CRUD logic should be made common and abstracted. Controllers are just not the right place; Factories (ie services) are.
You can use the same view on different controllers but it depends on what you are doing inside the view and whether or not the controller has the necessary members within the $scope object that are bound in the view. You can add an "action" variable on your $scope object and modify the view based on the same.
There is a new MVC mechanism built in Enyo 2.3pre but there is absolutely now docs on it.
The question is how can I bind specific controller to my view?
I have a new kind based on enyo.Control e.g. and I have a controller based on kind: 'enyo.ViewController',
In my controller I have handlers object with a function that should handle event.
If I put view prop into controller with a name of my view that doesn't work since
my handler in controller is not invoked
Can you post some examples on this?
So, the enyo.ViewController, by default, wants to renderInto document.body and we use it to define the enyo.Application kind as the "starting point" for your application.
The Enyo implementation is not necessarily "pure" MVC in the sense that you don't necessarily have to have a proper controller for every view (or enyo.Control) that you are dealing with. Enyo has always had a sort of hybrid view/controller system baked into the controls themselves.
With that being said, recent changes to the implementation removed bubbling of events to a "controller" that owned your "view" as it resulted in a lot of unnecessary overhead. In fact, we're removing the "controllers" block from the enyo.Application kind as an app-global reference to various controllers, and instead you will place them in a components block as typical of "traditional" Enyo development.
So, the current thinking is that your view will handle events as before, but you can bind to properties of various "controllers" and models.
Now, you can still create an MVC architecture if you really want to, but the system is flexible enough to support any of the "separation of concerns" methodologies (MVC, MVP, MVVM, etc.)
My current way of going about things is to create a "controller" for doing some things (like make Web service requests) and then build out models from the data I get back, add them to a collection, and then my views probably have a data-aware control (such as enyo.DataRepeater or enyo.DataList) that will automatically generate some rows for each model.
Take a look at this simple example: http://github.com/clinuz/college-football but, be advised it may not be up-to-date with the switch from app-wide controllers to components. And also, we're removing the "controller" property of the DataRepeater/List and it will change to "collection."
Let me know if you need some more hints. We're aware the lack of documentation is making this difficult while we finalize our implementation. Please bear with us!
You could see my example of to checkout enyo MVC structure.
https://github.com/prajnavantha/enyo-internetradio
Basically we have a model, view and controller.
models: In my case is a simple enyo.Model kind. U can have enyo.collections etc...
Controller: i've used enyo.ModelController.
Views: have the kinds:
The application is not totally MVC. Since my logic is still in views. However you can understand, how to set model and use the componenets.
I'm looking through examples on the AngularJS home page — specifically “Add Some Control”. I don’t quite understand how it maps to MVC pattern.
It’s more or less clear that the template (index.html) can be thought of as the view, objects constructed by TodoCtrl from todo.js as the controller, but where is a model? Attributes like ng-model map to some internal pieces of the framework and don’t directly expose an object which we could call a model.
Is it correct to call AngularJS an MVC framework?
The core idea behind MVC is that you have clear separation in your code between
managing its data (model), the application logic (controller), and presenting the data
to the user (view).
The view gets data from the model to display to the user. When a user interacts with the
application by clicking or typing, the controller responds by changing data in the model.
Finally, the model notifies the view that a change has occurred so that it can update what
it displays.
In Angular applications, the view is the Document Object Model (DOM), the controllers
are JavaScript classes, and the model data is stored in object properties.
I havent read up on Angular. However, keep in mind that "true" MVC means that the Model contains business Logic, the Controller takes care of communicating user input to the Model, and the View gets its own data from the Model. Many so called MVC frameworks are actually not implementing MVC the right way: They are overloading the Controller With to much responsibility, as in making the Controller responsible also to update the View. That is not what the Controller was intended to do, and in such cases you get what is called a "fat Controller". There is a misconseption among many webdevelopers that the View is simply a "template". This is both true and false; It is a template but it get its own data directly from the Model - not via the Controller.
But as I started out saying: I havent yet read up on Angular, but you might have so yourself and you should be able to find out if Angular is truly a MVC framework by looking at what the different Components in the Framework does.
The attributes map into the scope variable as defined in the controller. For example, if you have some JS objects which represent your business logic, you can put those in the scope variable, and then the attributes can be mapped into the model itself instead of some arbitrary values in the scope variable.
If anything that can store data in a object is considered a model than every front end framework (view) could be considered to have a model. They can all store data in objects and present them in the view. I think calling angular a mvc is really a marketing ploy, trying to make angular seem like it is more than it is.
See:
https://www.pluralsight.com/blog/software-development/tutorial-angularjs-mvc-implementation
In the controller, is where they give their example of angular's as a model. If it can't assist in the storage of persistent data it isn't much of a model.