S
In the web development you often hear people talking about the MVC framework and
the MVVM framework and so on.
What exactly are these frameworks?
How are they useful in doing web development?
Let's talk about that briefly next.
In the software engineering world,
you often hear people talking about design patterns.
What exactly they mean is to stop reinventing the wheel every single time.
A design pattern is a well-documented solution to a recurring problem.
Very often, you see yourself repeatedly solving similar problems.
If we have a well specified documentation of how to solve these problems,
why keep reinventing the wheel every single time?
So that is where the software
engineering's design pattern concept originates.
Sometimes you also see people referring to this as an architecture pattern.
So to summarize, software design patterns in particular are a reusable
solution to commonly occurring problems that are solved in software.
Now in this context, you often hear people talking about the gang of four.
This was a group of four authors that wrote this seminal book called
Design Patterns: Elements of Reusable Object-Oriented Software.
In this book, they identified a large set of commonly used design
patterns in software engineering.
This was one of the first well-documented exploration of design patterns,
and hence, became the gold standard for anybody working in
software engineering, especially concerned about design packets.
This software engineering pattern enables us to isolate
domain logic from the user interface.
So you're basically separating the user's view of the information
from the actual logic and how the information stored and manipulated.
Now this separation of concerns concept you're going to be hearing over and
over again in this context.
The separation of concerns is what facilitates independent development of
each of these three parts of our application and
also enables testing and maintenance of these different parts.
Now we can divide our entire application into three parts,
the view that is primarily concerned with presenting information to the user,
the model that stores the domain state and the domain logic and
also provides the way of
manipulating this state from the rest of the application and
the controller that mediates between the view and the model.
We'll talk about each of these three parts in a bit more detail next.
In the MVC framework, the model manages the behavior and
data of the application domain.
And the model responds to requests for information about its current state.
So typically when the view wants to render, or the view wants to update
itself, it might query the model in order to obtain information so
that it can be rendered appropriately to the user.
The model also will respond to requests for change of its state.
This is usually done through the control.
In an event-driven system,
the model also can be configured to notify observers.
So viewers can register themselves as observers for the model and so
when the model is updated the views will be automatically triggered to
update themselves based on the change to that model state.
The view itself is concern with presenting the information to the users in a user
interface element in such a way that it facilitates both the presentation of
information to the user and also enables the user to interact with the application.
So the view may represent one representation of the model state.
So, from single model, you can easily derive multiple ways
presenting this information to the user, depending upon for
example, depending upon the viewport size.
So a small size viewport like on a mobile application,
the information will be presented in a different way as opposed
to a larger view port that is facilitated on a desktop computer.
So in an MVC framework all the display of information has a one to
one correspondence with the model state.
The third piece of puzzle in the MCV framework is the controller.
The job of the controller is to receive information from the view.
So any user interaction that is performed will be captured and
then passed onto the controller in order to act on these user interactions.
And it is the job of the controller then to initiate a change of the state of
the model, if it is required in this particular situation.
So the controller will appropriately cause the change of the state of the model.
So to summarize, the controller can accept input
from the user in terms of the user interactions that have taken place, and
then it will instruct the model to change the state.
Simultaneously, the controller may also
cause the view to change the way the information is being shown in the view.
So that is the reason why in this picture you have two arrows
going from the controller, one towards the model and the other towards the view.
Sometimes you hear people talking about the model view view-model approach.
The model view view-model approach is, in some sense,
a derivative of the model view controller approach.
Sometimes you also hear people referring to it as the model
view view-binder approach.
In here, you have the model that represents the business logic and
the data for your application.
From the model, you derive a view-model, which encapsulates that
part of the information that is required for rendering a specific view.
So the view-model is the abstraction of the view that exposes
the public properties and the various commands that are available.
So this provides a declarative data binding.
In some sense, the way the component and
the templates in angular are implemented, it can be viewed as
a variant of the model view view-model approach.
With this quick understanding of the MVC and the MVVM framework,
let's now proceed to understand more about angular services.
S