Simply learning a framework is not enough on its own, It is best for us, in learning

and in practice, to understand why we should

be using a framework and how it helps us.

So what is a framework?

Let's start with a simple definition, a software framework is a

universal, reusable platform to develop

soft wire application product and solution.

Key words here to keep in

mind are Universal, Reusable, and Develop solutions.

Now we need to understand what all framework should help us accomplish.

These following four items, from the Wikipedia page on

software frameworks, are considered the distinguishing features of a framework.

Inversion of control, In a framework, unlike

libraries or normal user applications, the overall

program's flow of control is not dictated by the caller, but yet by the framework.

Default behaviour, a framework has the

default behavior, this default behavior must

be some kind of useful behavior, and not a series of no ops.

Extensibility, a framework can be extended by the user, usually by selective

over writing or specialized by user code, to provide specific functionality.

Non-modifiable framework code, the framework code in general is

not supposed to be modified, while accepting user implemented extensions.

In other words, users can extend the codes framework but should not modify it's code.

Aside from these four, Lorbel provides us with many

more useful features, and does a good job of

giving us a method of implementing, separation of concerns

through the use of MVC, or Model View Controller.

Briefly MVC is thus, a model which contains

our business logic and interaction with our application's data.

A view which presents the user visual data, and a method

of which to interact with our application as well as receive feedback.

A controller which accepts view, or user and

model input and then translates the interactions between them.

How the three components interact are quite important,

and represents the design side of the MVZ architecture.

You may or may not understand what the full power of

this system is, but in time it will become second nature.

Here are the Wikipedia descriptions of that design, to give us

a base understanding of how the process of our data moves.

A controller can send commands to the model to

update the model's state, such as editing a document.

It can also send commands to it's associated view, to change

the view's presentation of the model such as, scrolling through a document.

A model notifies it's associated views and controllers, when

there's been a change in it's state, this notification allows

the views to produce updated output, and the controllers

will be able to change the available set of commands.

In some cases, an MVC implementation might be instead passive, so that

other components must pull the model for updates rather than being notified.

A view, requests information from the model, that

it needs in generating output representation to the user.

Perhaps you're thinking, wow that's a lot to take in, if so, you're in

good company I felt this exact thing on my first lesson, immediately after that

fought my next wasn't denial why in the world do we need all this,

t's for sure a common question, one that I hope to answer in this course.