1
00:00:00,000 --> 00:00:04,480
[Muzikë]

2
00:00:04,480 --> 00:00:09,994
In the web development you often hear
people talking about the MVC framework and

3
00:00:09,994 --> 00:00:13,020
the MVVM framework and so on.

4
00:00:13,020 --> 00:00:14,460
What exactly are these frameworks?

5
00:00:15,560 --> 00:00:20,050
How are they useful in
doing web development?

6
00:00:20,050 --> 00:00:22,257
Let's talk about that briefly next.

7
00:00:24,177 --> 00:00:26,688
In the software engineering world,

8
00:00:26,688 --> 00:00:31,140
you often hear people talking
about design patterns.

9
00:00:31,140 --> 00:00:37,470
What exactly they mean is to stop
reinventing the wheel every single time.

10
00:00:37,470 --> 00:00:43,880
A design pattern is a well-documented
solution to a recurring problem.

11
00:00:43,880 --> 00:00:48,540
Very often, you see yourself
repeatedly solving similar problems.

12
00:00:48,540 --> 00:00:53,860
If we have a well specified documentation
of how to solve these problems,

13
00:00:53,860 --> 00:00:56,720
why keep reinventing
the wheel every single time?

14
00:00:56,720 --> 00:00:59,140
So that is where the software

15
00:00:59,140 --> 00:01:03,220
engineering's design
pattern concept originates.

16
00:01:03,220 --> 00:01:08,420
Sometimes you also see people referring
to this as an architecture pattern.

17
00:01:08,420 --> 00:01:13,094
So to summarize, software design
patterns in particular are a reusable

18
00:01:13,094 --> 00:01:17,706
solution to commonly occurring
problems that are solved in software.

19
00:01:17,706 --> 00:01:22,209
Now in this context, you often hear
people talking about the gang of four.

20
00:01:23,830 --> 00:01:29,217
This was a group of four authors
that wrote this seminal book called

21
00:01:29,217 --> 00:01:35,390
Design Patterns: Elements of
Reusable Object-Oriented Software.

22
00:01:35,390 --> 00:01:39,500
In this book, they identified
a large set of commonly used design

23
00:01:39,500 --> 00:01:41,770
patterns in software engineering.

24
00:01:41,770 --> 00:01:48,030
This was one of the first well-documented
exploration of design patterns,

25
00:01:48,030 --> 00:01:53,370
and hence, became the gold standard for
anybody working in

26
00:01:53,370 --> 00:01:58,410
software engineering,
especially concerned about design packets.

27
00:01:58,410 --> 00:02:03,320
This software engineering
pattern enables us to isolate

28
00:02:03,320 --> 00:02:06,706
domain logic from the user interface.

29
00:02:06,706 --> 00:02:11,827
So you're basically separating
the user's view of the information

30
00:02:11,827 --> 00:02:17,146
from the actual logic and how
the information stored and manipulated.

31
00:02:17,146 --> 00:02:22,280
Now this separation of concerns concept
you're going to be hearing over and

32
00:02:22,280 --> 00:02:25,600
over again in this context.

33
00:02:25,600 --> 00:02:30,290
The separation of concerns is what
facilitates independent development of

34
00:02:30,290 --> 00:02:34,700
each of these three parts
of our application and

35
00:02:34,700 --> 00:02:39,350
also enables testing and
maintenance of these different parts.

36
00:02:39,350 --> 00:02:42,640
Now we can divide our entire
application into three parts,

37
00:02:42,640 --> 00:02:46,820
the view that is primarily concerned
with presenting information to the user,

38
00:02:46,820 --> 00:02:51,930
the model that stores the domain state and
the domain logic and

39
00:02:51,930 --> 00:02:57,430
also provides the way of

40
00:02:57,430 --> 00:03:02,604
manipulating this state from
the rest of the application and

41
00:03:02,604 --> 00:03:08,180
the controller that mediates
between the view and the model.

42
00:03:08,180 --> 00:03:12,550
We'll talk about each of these three
parts in a bit more detail next.

43
00:03:12,550 --> 00:03:17,360
In the MVC framework,
the model manages the behavior and

44
00:03:17,360 --> 00:03:19,760
data of the application domain.

45
00:03:19,760 --> 00:03:25,433
And the model responds to requests for
information about its current state.

46
00:03:25,433 --> 00:03:30,374
So typically when the view wants to
render, or the view wants to update

47
00:03:30,374 --> 00:03:35,065
itself, it might query the model
in order to obtain information so

48
00:03:35,065 --> 00:03:38,703
that it can be rendered
appropriately to the user.

49
00:03:38,703 --> 00:03:45,632
The model also will respond to
requests for change of its state.

50
00:03:45,632 --> 00:03:48,574
This is usually done through the control.

51
00:03:48,574 --> 00:03:51,712
In an event-driven system,

52
00:03:51,712 --> 00:03:57,810
the model also can be
configured to notify observers.

53
00:03:57,810 --> 00:04:02,670
So viewers can register themselves
as observers for the model and so

54
00:04:02,670 --> 00:04:06,940
when the model is updated the views
will be automatically triggered to

55
00:04:06,940 --> 00:04:10,960
update themselves based on
the change to that model state.

56
00:04:12,160 --> 00:04:17,290
The view itself is concern with presenting
the information to the users in a user

57
00:04:17,290 --> 00:04:23,690
interface element in such a way that
it facilitates both the presentation of

58
00:04:23,690 --> 00:04:29,630
information to the user and also enables
the user to interact with the application.

59
00:04:29,630 --> 00:04:33,970
So the view may represent one
representation of the model state.

60
00:04:33,970 --> 00:04:38,662
So, from single model,
you can easily derive multiple ways

61
00:04:38,662 --> 00:04:43,449
presenting this information to the user,
depending upon for

62
00:04:43,449 --> 00:04:47,051
example, depending upon the viewport size.

63
00:04:47,051 --> 00:04:51,840
So a small size viewport like
on a mobile application,

64
00:04:51,840 --> 00:04:57,359
the information will be presented
in a different way as opposed

65
00:04:57,359 --> 00:05:03,000
to a larger view port that is
facilitated on a desktop computer.

66
00:05:04,248 --> 00:05:08,620
So in an MVC framework all the display
of information has a one to

67
00:05:08,620 --> 00:05:13,490
one correspondence with the model state.

68
00:05:15,850 --> 00:05:20,380
The third piece of puzzle in the MCV
framework is the controller.

69
00:05:21,400 --> 00:05:26,750
The job of the controller is to
receive information from the view.

70
00:05:26,750 --> 00:05:30,500
So any user interaction that is
performed will be captured and

71
00:05:30,500 --> 00:05:35,720
then passed onto the controller in order
to act on these user interactions.

72
00:05:35,720 --> 00:05:40,040
And it is the job of the controller then
to initiate a change of the state of

73
00:05:40,040 --> 00:05:46,870
the model, if it is required
in this particular situation.

74
00:05:46,870 --> 00:05:51,940
So the controller will appropriately cause
the change of the state of the model.

75
00:05:51,940 --> 00:05:55,940
So to summarize,
the controller can accept input

76
00:05:55,940 --> 00:06:00,860
from the user in terms of the user
interactions that have taken place, and

77
00:06:00,860 --> 00:06:06,935
then it will instruct
the model to change the state.

78
00:06:06,935 --> 00:06:09,500
Simultaneously, the controller may also

79
00:06:09,500 --> 00:06:14,470
cause the view to change the way the
information is being shown in the view.

80
00:06:14,470 --> 00:06:19,230
So that is the reason why in
this picture you have two arrows

81
00:06:19,230 --> 00:06:24,000
going from the controller, one towards
the model and the other towards the view.

82
00:06:25,060 --> 00:06:29,910
Sometimes you hear people talking about
the model view view-model approach.

83
00:06:29,910 --> 00:06:33,490
The model view view-model approach is,
in some sense,

84
00:06:33,490 --> 00:06:37,050
a derivative of the model
view controller approach.

85
00:06:37,050 --> 00:06:40,620
Sometimes you also hear people
referring to it as the model

86
00:06:40,620 --> 00:06:41,768
view view-binder approach.

87
00:06:41,768 --> 00:06:45,502
In here, you have the model that
represents the business logic and

88
00:06:45,502 --> 00:06:47,311
the data for your application.

89
00:06:47,311 --> 00:06:52,367
From the model, you derive a view-model,
which encapsulates that

90
00:06:52,367 --> 00:06:58,095
part of the information that is
required for rendering a specific view.

91
00:06:58,095 --> 00:07:02,635
So the view-model is the abstraction
of the view that exposes

92
00:07:02,635 --> 00:07:07,395
the public properties and
the various commands that are available.

93
00:07:07,395 --> 00:07:10,125
So this provides
a declarative data binding.

94
00:07:11,690 --> 00:07:16,300
In some sense, the way the component and

95
00:07:16,300 --> 00:07:21,520
the templates in angular are implemented,
it can be viewed as

96
00:07:21,520 --> 00:07:27,250
a variant of the model
view view-model approach.

97
00:07:27,250 --> 00:07:32,006
With this quick understanding of
the MVC and the MVVM framework,

98
00:07:32,006 --> 00:07:36,686
let's now proceed to understand
more about angular services.

99
00:07:36,686 --> 00:07:43,099
[Muzikë]