1
00:00:00,040 --> 00:00:02,120
Hey there, and welcome to the 
deep dive. 

2
00:00:02,520 --> 00:00:05,280
If you're looking to cut through
the tech jargon and get straight

3
00:00:05,280 --> 00:00:08,880
to what really matters in 
complex topics, well, you're in 

4
00:00:08,880 --> 00:00:11,520
the right place. 
Today we're tackling something 

5
00:00:11,520 --> 00:00:15,000
pretty foundational in software 
engineering, the model, view 

6
00:00:15,000 --> 00:00:19,160
controller, or MVC pattern. 
You might not realize it, but 

7
00:00:19,160 --> 00:00:23,840
this architecture has quietly 
shaped how we interact with 

8
00:00:23,840 --> 00:00:25,840
digital applications every 
single day. 

9
00:00:26,280 --> 00:00:29,120
We've got some fantastic source 
material that really unpacks 

10
00:00:29,120 --> 00:00:33,040
MVC, tracing its evolution from 
its, you know, pioneering 

11
00:00:33,040 --> 00:00:35,600
origins right up to the web 
applications and single page 

12
00:00:35,600 --> 00:00:38,960
apps we use constantly. 
Now, our mission, it's simple to

13
00:00:38,960 --> 00:00:41,920
give you a clear understanding 
of what MVC actually is, why 

14
00:00:41,920 --> 00:00:44,840
it's been so powerful for so 
long, and how it's adapted over 

15
00:00:44,840 --> 00:00:46,640
the decades. 
OK, let's peel back the layers. 

16
00:00:46,640 --> 00:00:49,400
Let's see how this classic 
design still underpins so much 

17
00:00:49,400 --> 00:00:51,800
of our digital world. 
It really is fascinating. 

18
00:00:51,800 --> 00:00:53,480
Is it? 
What our sources highlight is 

19
00:00:53,480 --> 00:00:57,360
how a design pattern thought up,
you know, decades ago continues 

20
00:00:57,360 --> 00:00:58,920
to be so relevant in modern 
software. 

21
00:00:58,920 --> 00:01:01,080
We'll definitely trace that 
history and hopefully we can 

22
00:01:01,080 --> 00:01:03,800
clear up some of the common 
confusions people have about it 

23
00:01:03,800 --> 00:01:05,080
along the way. 
Right. 

24
00:01:05,239 --> 00:01:08,440
And to really get MVC, we kind 
of have to rewind, don't we? 

25
00:01:08,880 --> 00:01:12,360
Back to the late 1970s. 
It's hard to imagine now, but 

26
00:01:12,360 --> 00:01:15,680
this was an era dominated by 
text based command line stuff. 

27
00:01:15,680 --> 00:01:18,720
Screens were just characters. 
But then this truly 

28
00:01:18,720 --> 00:01:21,480
groundbreaking object oriented 
language popped up. 

29
00:01:21,640 --> 00:01:23,120
Small Talk 80. 
Exactly. 

30
00:01:23,120 --> 00:01:25,520
Small talk 80. 
It wasn't just about object 

31
00:01:25,520 --> 00:01:27,360
oriented programming, though 
that was huge. 

32
00:01:28,080 --> 00:01:31,320
It was a massive leap forward in
making graphical user 

33
00:01:31,320 --> 00:01:34,760
interfaces, Guis, accessible. 
We're talking the first real 

34
00:01:34,760 --> 00:01:38,840
widespread use of Windows 
buttons, scroll bars, even the 

35
00:01:38,840 --> 00:01:40,720
mouse for like a broader 
audience. 

36
00:01:40,720 --> 00:01:43,160
It was a completely radical 
shift in how people interacted 

37
00:01:43,160 --> 00:01:45,880
with computers and MVC. 
That was the architectural 

38
00:01:45,880 --> 00:01:48,480
pattern small talks designers 
picked to actually build these 

39
00:01:48,480 --> 00:01:51,520
complex graphical interfaces. 
OK, so in that context, this 

40
00:01:51,520 --> 00:01:54,520
brand new GY world, what exactly
was MVC proposing? 

41
00:01:54,600 --> 00:01:57,440
Our sources explain it, 
introduce this well, paradigm 

42
00:01:57,440 --> 00:01:59,600
shifting idea. 
System classes should be 

43
00:01:59,600 --> 00:02:02,600
organized into 3 distinct, 
pretty specialized groups. 

44
00:02:02,680 --> 00:02:05,000
Yeah, let's break those down 
because understanding these core

45
00:02:05,000 --> 00:02:09,360
jobs is really key. 
First, the view. 

46
00:02:09,880 --> 00:02:12,920
These are the classes directly 
responsible for the graphical 

47
00:02:12,920 --> 00:02:15,240
interface itself. 
You know everything you see and 

48
00:02:15,240 --> 00:02:17,640
interact with. 
The windows, buttons, menus, the

49
00:02:17,640 --> 00:02:19,440
visual display a. 
Little frent end stuff 

50
00:02:19,440 --> 00:02:20,360
basically. 
Pretty much. 

51
00:02:20,680 --> 00:02:22,920
Then you have the controller. 
These classes are like the 

52
00:02:22,920 --> 00:02:24,680
listeners. 
They handle events coming from 

53
00:02:24,680 --> 00:02:28,120
input devices, a mouse click 
typing on the keyboard. 

54
00:02:28,760 --> 00:02:31,640
A controller then figures out 
what that input means and can 

55
00:02:31,640 --> 00:02:34,800
ask for changes either to the 
models data or maybe the views 

56
00:02:34,800 --> 00:02:37,560
appearance. 
So like clicking A+ button on a 

57
00:02:37,560 --> 00:02:40,120
calculator, the controller tell 
the model hey update your 

58
00:02:40,120 --> 00:02:42,960
calculation. 
Or maybe clicking a dark UI 

59
00:02:42,960 --> 00:02:45,640
button the controller tells the 
view change your colors. 

60
00:02:45,800 --> 00:02:47,680
Got it. 
Input handler and director. 

61
00:02:47,800 --> 00:02:49,080
Kind of. 
Exactly. 

62
00:02:49,600 --> 00:02:51,880
And 3rd, crucially, there's the 
model. 

63
00:02:52,440 --> 00:02:58,440
These classes are where the 
applications Core Data and it's 

64
00:02:58,440 --> 00:03:01,760
business logic actually live. 
They hold the what of the 

65
00:03:01,760 --> 00:03:04,480
application and they're 
completely unaware of how that 

66
00:03:04,480 --> 00:03:06,680
data gets displayed or how users
interact with it. 

67
00:03:06,920 --> 00:03:09,920
They don't know about the view 
or the controller, No dependency

68
00:03:09,920 --> 00:03:11,600
there. 
They just manage the application

69
00:03:11,600 --> 00:03:13,760
state and you know the 
operations on that data. 

70
00:03:14,120 --> 00:03:16,880
So putting it together, the 
graphical interface part, what 

71
00:03:16,880 --> 00:03:19,840
the user sees and clicks is 
essentially split between the 

72
00:03:19,840 --> 00:03:22,280
view and the controller. 
But our storage material also 

73
00:03:22,280 --> 00:03:25,040
flags that this distinction. 
Well, it isn't always perfectly 

74
00:03:25,040 --> 00:03:27,200
clean in practice. 
Sometimes it simplifies more to 

75
00:03:27,200 --> 00:03:29,080
just graphical interface plus 
model. 

76
00:03:29,080 --> 00:03:31,040
Is that a common thing? 
That's a really sharp 

77
00:03:31,040 --> 00:03:32,920
observation, and yes, absolutely
true. 

78
00:03:33,400 --> 00:03:35,880
As Martin Fowler points out and 
one of our sources, even way 

79
00:03:35,880 --> 00:03:38,880
back in the small talk days, 
many implementations didn't 

80
00:03:38,880 --> 00:03:41,760
always keep a super strict 
separation between view and 

81
00:03:41,760 --> 00:03:44,640
controller. 
The fundamental insight though, 

82
00:03:44,640 --> 00:03:47,680
the real take away is this key 
deendency direction. 

83
00:03:48,640 --> 00:03:51,640
The graphical interface, the 
view controller combo. 

84
00:03:52,040 --> 00:03:55,800
It deends on the model, but the 
model, the data and the core 

85
00:03:55,800 --> 00:03:59,360
logic, it stays completely 
independent, knows nothing about

86
00:03:59,360 --> 00:04:00,920
the graphics. 
You can kind of picture it like 

87
00:04:01,040 --> 00:04:03,520
the graphical interface is 
constantly watching the model. 

88
00:04:03,760 --> 00:04:06,600
When the model state changes, 
the interface knows OK, I need 

89
00:04:06,600 --> 00:04:09,880
to update myself. 
OK, that separation of concerns 

90
00:04:09,880 --> 00:04:12,680
sounds incredibly useful, 
especially when you think about 

91
00:04:12,920 --> 00:04:15,160
building bigger, more complex 
applications. 

92
00:04:15,360 --> 00:04:17,640
What are the big advantages this
pattern brings? 

93
00:04:17,880 --> 00:04:20,600
Oh, there are several really 
compelling reasons NBC caught on

94
00:04:20,600 --> 00:04:22,720
so widely and why it's still 
relevant. 

95
00:04:23,000 --> 00:04:25,320
First, specialization of 
development work. 

96
00:04:25,640 --> 00:04:28,880
It really lets teams specialize.
You can have front end folks who

97
00:04:28,880 --> 00:04:32,520
are experts in UI focusing just 
on the view and controller, and 

98
00:04:32,520 --> 00:04:35,240
then other developers can 
concentrate purely on the models

99
00:04:35,240 --> 00:04:38,520
tricky business logic without 
needing to get bogged down in UI

100
00:04:38,520 --> 00:04:40,520
code. 
It just streamlines things a 

101
00:04:40,520 --> 00:04:41,320
lot. 
Makes sense. 

102
00:04:41,360 --> 00:04:45,560
Divide and conquer, right? 
Second, multiple views for the 

103
00:04:45,560 --> 00:04:47,720
same model. 
Think about having the same 

104
00:04:47,720 --> 00:04:50,440
underlying data shown in totally
different ways. 

105
00:04:50,880 --> 00:04:52,520
NBC makes this pretty 
straightforward. 

106
00:04:52,520 --> 00:04:54,760
Our source gives a great 
example, a model that just 

107
00:04:54,760 --> 00:04:58,040
stores hours and minutes. 
That same model can power both 

108
00:04:58,040 --> 00:05:02,040
an old school analog clock face 
and a digital time display at 

109
00:05:02,040 --> 00:05:04,600
the same time. 
That gives you huge flexibility 

110
00:05:04,600 --> 00:05:07,640
and helps reuse code. 
Yeah, I can see that like 

111
00:05:07,640 --> 00:05:09,800
different dashboards showing the
same core data. 

112
00:05:09,960 --> 00:05:12,440
Exactly. 
And 3rd, enhanced testability. 

113
00:05:12,880 --> 00:05:15,440
Things without a visual 
component like the classes in 

114
00:05:15,440 --> 00:05:18,800
your model are just inherently 
easier to write automated tests 

115
00:05:18,800 --> 00:05:20,640
for. 
By separating the view and 

116
00:05:20,640 --> 00:05:23,920
controller cleanly from the 
model, develoers can test the 

117
00:05:23,920 --> 00:05:26,680
core business logic much more 
thoroughly, much more 

118
00:05:26,680 --> 00:05:28,920
efficiently. 
And that leads to, you know, 

119
00:05:28,920 --> 00:05:32,000
more robust software. 
Yeah, testing GUI is notoriously

120
00:05:32,000 --> 00:05:35,880
tricky, so isolating the logic 
helps massively there. 

121
00:05:36,040 --> 00:05:38,440
And the source really hammers 
this home with that powerful 

122
00:05:38,440 --> 00:05:41,240
quote from Fowler and Beck, 
calling the separation of UI 

123
00:05:41,240 --> 00:05:44,600
code and domain logic the gold 
at the heart of MVC. 

124
00:05:44,880 --> 00:05:48,000
What is it about that specific 
separation that's so profoundly 

125
00:05:48,000 --> 00:05:51,440
useful for developers? 
It's so impactful because it 

126
00:05:51,440 --> 00:05:55,200
tackles complexity head on. 
Building software is hard, right

127
00:05:55,520 --> 00:05:58,200
by drawing a really clear line 
between what the application 

128
00:05:58,200 --> 00:06:02,480
does, the business rules, the 
data that's the model and how it

129
00:06:02,480 --> 00:06:04,720
was presented to the user and 
interacted with the view and 

130
00:06:04,720 --> 00:06:06,600
controller. 
You basically create these 

131
00:06:06,600 --> 00:06:10,160
modules, these pieces that are 
much simpler to change, to 

132
00:06:10,160 --> 00:06:12,160
maintain, and to evolve 
independently. 

133
00:06:12,800 --> 00:06:15,280
This fundamental separation 
leads to cleaner code, it's more

134
00:06:15,280 --> 00:06:19,640
modular, and critically, it lets
you have multiple different ways

135
00:06:19,640 --> 00:06:22,760
of presenting the exact same 
business logic without having to

136
00:06:22,760 --> 00:06:24,320
copy that core logic all over 
the place. 

137
00:06:24,320 --> 00:06:26,120
OK, that really clarifies the 
core value. 

138
00:06:26,120 --> 00:06:28,560
Now, something that often trips 
people up is the relationship 

139
00:06:28,560 --> 00:06:31,800
between MVC and three tier 
architectures. 

140
00:06:32,240 --> 00:06:34,440
Our source gives a great 
historical perspective to 

141
00:06:34,440 --> 00:06:36,720
untangle this. 
How did these two concepts 

142
00:06:36,720 --> 00:06:38,840
relate initially? 
Yeah, this is a really important

143
00:06:38,840 --> 00:06:41,920
distinction to make because they
are both architectural patterns,

144
00:06:42,480 --> 00:06:44,960
but their origins and their main
goals were actually quite 

145
00:06:44,960 --> 00:06:48,160
different back in the day. 
So MVC's genesis, like we said, 

146
00:06:48,400 --> 00:06:51,880
MVC came about in the late 70s 
specifically to deal with the 

147
00:06:51,880 --> 00:06:54,880
complexity of Guis inside single
applications. 

148
00:06:55,240 --> 00:06:58,160
Think early desktop software, 
maybe an office suite like Word 

149
00:06:58,160 --> 00:06:59,680
or Excel. 
Right, self-contained 

150
00:06:59,680 --> 00:07:00,920
applications. 
Exactly. 

151
00:07:01,120 --> 00:07:04,720
Then, three tiers emergence. 
Fast forward to the 1990s. 

152
00:07:05,200 --> 00:07:07,760
The whole world is changing with
networks, distributed systems 

153
00:07:07,760 --> 00:07:10,520
becoming the norm. 3 tier 
architectures really rose to 

154
00:07:10,520 --> 00:07:12,880
prominence. 
Then they separated the system 

155
00:07:12,880 --> 00:07:16,160
into distinct layers. 
A client, usually the user 

156
00:07:16,160 --> 00:07:18,760
interface layer, an application 
layer with a business logic 

157
00:07:18,760 --> 00:07:21,600
lived off and on a server and a 
database layer for storage. 

158
00:07:22,040 --> 00:07:25,120
Now in that kind of setup, NBC 
wasn't really a competitor. 

159
00:07:25,120 --> 00:07:27,720
It could actually be used inside
the presentation layer, the 

160
00:07:27,720 --> 00:07:30,200
client layer of a bigger 3 tier 
system. 

161
00:07:30,240 --> 00:07:32,480
You might have had, say, a 
complex Windows application 

162
00:07:32,480 --> 00:07:35,880
using MVC for its UI, but that 
application was just one part of

163
00:07:35,880 --> 00:07:37,320
a larger distributed system. 
Ah. 

164
00:07:37,680 --> 00:07:40,160
OK, so it wasn't an either 
situation back then. 

165
00:07:40,160 --> 00:07:43,960
It was more like MVC could be 
part of a tier in a three tier 

166
00:07:43,960 --> 00:07:46,160
system like Russ and Dolls 
almost. 

167
00:07:46,160 --> 00:07:48,400
That clears up a lot of that 
historical confusion for me. 

168
00:07:48,400 --> 00:07:50,840
But then then the web happened. 
Everything changed again. 

169
00:07:50,920 --> 00:07:52,880
Absolutely. 
The web just exploded around the

170
00:07:52,880 --> 00:07:56,440
year 2000, became ubiquitous, 
and suddenly user interfaces 

171
00:07:56,440 --> 00:07:58,600
weren't complex desktop apps 
anymore. 

172
00:07:58,600 --> 00:08:02,440
They were migrating to HTML and 
JavaScript running inside web 

173
00:08:02,440 --> 00:08:04,520
browsers. 
And this is where the lines 

174
00:08:04,520 --> 00:08:07,800
really started to blur, mainly 
because these new powerful web 

175
00:08:07,800 --> 00:08:10,160
frameworks started popping up. 
Things like Spring in the Java 

176
00:08:10,160 --> 00:08:14,560
world, Ruby on Rails, Django and
Python, Blairville and PHP, and 

177
00:08:14,560 --> 00:08:17,360
they all decided to call 
themselves MVC frameworks. 

178
00:08:17,560 --> 00:08:21,080
OK, so they adopted the name 
MVC, but given how different the

179
00:08:21,080 --> 00:08:23,240
web is, stateless request 
response. 

180
00:08:23,240 --> 00:08:26,320
Was it the same NBC as the Small
Talk original or was it more of 

181
00:08:26,320 --> 00:08:29,320
an adaptation? 
It was definitely an adaptation,

182
00:08:29,480 --> 00:08:32,600
A reinterpretation really 
tailored for the web specific 

183
00:08:32,600 --> 00:08:34,400
nature. 
In these these web frameworks, 

184
00:08:34,400 --> 00:08:37,600
the view typically became 
dynamic HTML pages, often 

185
00:08:37,600 --> 00:08:40,320
generated on the server side. 
The controllers became 

186
00:08:40,320 --> 00:08:43,440
components that handled incoming
web requests, figured out what 

187
00:08:43,440 --> 00:08:46,120
data was needed from the model, 
and then decided which view to 

188
00:08:46,120 --> 00:08:47,840
render and send back to the 
browser. 

189
00:08:48,280 --> 00:08:52,280
And the model layer, well, that 
often became primarily about 

190
00:08:52,280 --> 00:08:54,600
data persistence, the code to 
talk to the database. 

191
00:08:55,200 --> 00:08:57,520
So while these modern web 
systems functionally often look 

192
00:08:57,520 --> 00:09:01,360
a lot like 3 tier systems, these
incredibly popular frameworks 

193
00:09:01,360 --> 00:09:06,120
chose to use those familiar MVC 
terms, and that fundamentally 

194
00:09:06,120 --> 00:09:08,320
shaped how developers thought 
about building web apps for 

195
00:09:08,320 --> 00:09:09,760
many, many years. 
Right. 

196
00:09:09,760 --> 00:09:12,080
So maybe the best way for us to 
think about it now is that there

197
00:09:12,080 --> 00:09:15,480
are kind of two main flavors, 
the original classic small talk 

198
00:09:15,480 --> 00:09:19,040
80 version for GOYS and then 
this widely adopted web version,

199
00:09:19,320 --> 00:09:22,000
which as you explained, bars the
terms, but acts a lot like a 

200
00:09:22,000 --> 00:09:23,840
three tier setup tailored for 
the web. 

201
00:09:24,200 --> 00:09:26,240
That's a very good way to 
summarize it. 2 distinct 

202
00:09:26,240 --> 00:09:29,080
contexts, similar terminology 
causing a bit of confusion 

203
00:09:29,080 --> 00:09:31,360
sometimes. 
OK, let's Fast forward again. 

204
00:09:32,200 --> 00:09:35,040
The web hasn't stood still. 
Obviously we've seen another 

205
00:09:35,040 --> 00:09:38,280
major shift with single page 
applications Spas. 

206
00:09:38,720 --> 00:09:43,280
How do these more modern dynamic
client heavy applications fit 

207
00:09:43,280 --> 00:09:46,160
into the MVC picture? 
That's a great next step, 

208
00:09:46,160 --> 00:09:49,600
because Spas really did change 
the user experience on the web. 

209
00:09:50,040 --> 00:09:53,000
Think about traditional web as 
often every time you click 

210
00:09:53,000 --> 00:09:56,160
something or submit a form, the 
browser has to go back to the 

211
00:09:56,160 --> 00:09:59,800
server, get a whole new page, 
and redraw everything. 

212
00:09:59,920 --> 00:10:01,880
That can feel slow, a bit 
clunky. 

213
00:10:02,360 --> 00:10:05,760
SB As aim to fix that to make 
web apps feel much more like 

214
00:10:05,760 --> 00:10:08,680
native desktop applications 
right there in your browser. 

215
00:10:08,720 --> 00:10:11,480
So less of that constant page 
reloading, that flash of white 

216
00:10:11,480 --> 00:10:14,480
screen, more fluid. 
Exactly when you first load an 

217
00:10:14,480 --> 00:10:17,000
SBA, something like Gmail is a 
classic example. 

218
00:10:17,240 --> 00:10:20,120
The browser downloads most of 
the applications code upfront, 

219
00:10:20,440 --> 00:10:23,800
the HTML structure, the CSS for 
styling, and crucially, a lot of

220
00:10:23,800 --> 00:10:25,920
JavaScript. 
From then on, when you interact 

221
00:10:25,920 --> 00:10:28,000
with it, most of the action 
happens right there in your 

222
00:10:28,000 --> 00:10:30,160
browser. 
The logic and the presentation 

223
00:10:30,160 --> 00:10:31,960
rendering are largely client 
side. 

224
00:10:32,200 --> 00:10:34,760
That's what creates that much 
smoother, much more interactive,

225
00:10:34,760 --> 00:10:37,160
responsive feel. 
But even though all this magic 

226
00:10:37,160 --> 00:10:39,600
is happening in the browser, 
they still need to talk to a 

227
00:10:39,600 --> 00:10:42,320
server for data, right? 
It's not completely offline. 

228
00:10:42,480 --> 00:10:44,000
Absolutely. 
There's definitely still a 

229
00:10:44,000 --> 00:10:46,360
server component. 
You need somewhere to store the 

230
00:10:46,360 --> 00:10:49,480
data permanently, handle 
authentication, perform complex 

231
00:10:49,480 --> 00:10:52,480
operations. 
When an SPA needs new data, 

232
00:10:52,480 --> 00:10:54,880
maybe new emails arrive in 
Gmail. 

233
00:10:55,160 --> 00:10:58,080
It communicates asynchronously 
with the server, usually using 

234
00:10:58,080 --> 00:11:02,320
AP is it fetches just the new 
data it needs and updates only 

235
00:11:02,320 --> 00:11:04,960
the relevant parts of the 
screen, all without doing a full

236
00:11:04,960 --> 00:11:07,280
page reload. 
Our source material touches on a

237
00:11:07,280 --> 00:11:09,680
simple example using a framework
like Vue JS. 

238
00:11:09,840 --> 00:11:12,640
What's the key take away from 
that regarding MVC concepts in 

239
00:11:12,640 --> 00:11:14,920
the SPA world? 
What's really interesting is how

240
00:11:14,960 --> 00:11:18,760
Spas, even if not explicitly 
called MVC framework, sometimes 

241
00:11:19,320 --> 00:11:22,240
implicitly follow a very similar
architectural pattern. 

242
00:11:22,800 --> 00:11:26,040
In that Vue JS example, the 
interface components handling 

243
00:11:26,040 --> 00:11:29,800
both the presentation view and 
user input controller functions 

244
00:11:30,080 --> 00:11:33,080
are largely implemented within 
the HTML templates and 

245
00:11:33,080 --> 00:11:36,200
associated JavaScript components
that manage that specific piece 

246
00:11:36,200 --> 00:11:39,720
of UI and the model holding the 
application state. 

247
00:11:39,880 --> 00:11:43,080
That dynamic data that's 
typically managed within plain 

248
00:11:43,080 --> 00:11:46,240
JavaScript objects or data 
structures within the SP as 

249
00:11:46,240 --> 00:11:47,680
code. 
So the separation is still 

250
00:11:47,680 --> 00:11:50,080
there, just implemented with 
different web technologies. 

251
00:11:50,160 --> 00:11:52,880
Precisely, and there's a 
specific feature often found in 

252
00:11:52,880 --> 00:11:55,440
these SPA frameworks that really
makes this connection work 

253
00:11:55,440 --> 00:11:57,320
smoothly. 
You're talking about data 

254
00:11:57,320 --> 00:11:58,680
binding. 
Exactly. 

255
00:11:58,800 --> 00:12:03,080
Often two way data binding 
frameworks like Vue JS, Angular,

256
00:12:03,080 --> 00:12:06,720
React handle this in different 
ways, but the core idea is 

257
00:12:06,720 --> 00:12:08,720
powerful. 
They provide mechanisms to 

258
00:12:08,720 --> 00:12:11,760
automatically synchronize data 
between your model, your 

259
00:12:11,760 --> 00:12:14,640
JavaScript data and your view 
what's shown on the screen. 

260
00:12:14,960 --> 00:12:17,640
So if a value changes in your 
model, the framework 

261
00:12:17,640 --> 00:12:20,080
automatically updates the 
relevant part of the UI. 

262
00:12:20,560 --> 00:12:23,120
And often if the user changes 
something in the UI, like typing

263
00:12:23,120 --> 00:12:26,360
in a form field, that change can
be automatically reflected back 

264
00:12:26,360 --> 00:12:28,920
into the model data. 
It really simplifies keeping the

265
00:12:28,920 --> 00:12:31,200
UI in the application state In 
Sync. 

266
00:12:31,720 --> 00:12:35,160
So from small talk G wise 
through web frameworks to modern

267
00:12:35,160 --> 00:12:39,000
SP as these core ideas of 
separating data presentation and

268
00:12:39,000 --> 00:12:41,720
control logic have proven 
incredibly resilient and 

269
00:12:41,720 --> 00:12:44,080
adaptable. 
They really have the specific 

270
00:12:44,080 --> 00:12:46,960
implementation details change 
with technology, but that 

271
00:12:46,960 --> 00:12:49,480
fundamental principle of 
separation of concerns remains 

272
00:12:49,480 --> 00:12:52,000
incredibly valuable. 
And that brings us pretty much 

273
00:12:52,000 --> 00:12:56,360
to the end of this deep dive 
into MVC architecture, from its 

274
00:12:56,640 --> 00:12:59,960
pioneering roots way back in 
small talk, right through to its

275
00:12:59,960 --> 00:13:02,240
modern adaptations in web 
framework works and these 

276
00:13:02,240 --> 00:13:04,160
sophisticated single page 
applications. 

277
00:13:04,480 --> 00:13:06,960
We really hope this gave you a 
clearer picture of this 

278
00:13:06,960 --> 00:13:10,160
foundational yet everevolving 
concept in software design. 

279
00:13:10,200 --> 00:13:11,360
Yeah. 
Thanks for joining us for this 

280
00:13:11,360 --> 00:13:12,040
exploration.