5.1 Design Pattern MVC

00:00

I welcome the module five sequel development. This is less than one skim a development were the first sub lesson one point to design patterns

00:09

in this lesson, we're gonna discuss the approach were run to take when developing the skimmer for our application.

00:15

Um, and the next lesson will actually go over the requirements for our applications so we can better define what models and relationships we use. But in this lesson, we're just going to discuss the approach we're going to take now. What is the design pattern? Design pattern is an approach to designing software or programming that follows a

00:34

said pattern.

00:36

And the one that we're going to be looking at is model view controller. In fact, we're more concerned with the model,

00:44

So this is gonna be even easier for us

00:47

because we're gonna be concerned with the model which is in the database. We're not really gonna be concerned with the view

00:52

or the controller,

00:54

so that would make it a little bit easier for us. So why aren't we concerned with this? Well, because this is actually

01:00

ah, part of full stack development. So we were doing full stack development. We would be concerned with every part of this idea,

01:08

but right now we are strictly focused on the database or sequel.

01:14

Now the view and the controller would typically exist an application code. So that would be the PHP frameworks, like Clarabell or

01:23

Ruby or SP dot net and various other languages. But when we're dealing with the database, we're gonna be pretty much focused just on the model.

01:33

Um, so we're gonna discuss the ideas around creating models and creating relationships between those models. So let's go ahead and take a look at that.

01:42

So what is a model? Well, it's it's basically a noun, so it's a person, place or thing.

01:49

So

01:51

and model is also a table in a database.

01:56

I'm going to quote that out so it doesn't turn

01:59

that color on me.

02:01

So, for example, we could have a model or table called persons,

02:08

and each record in that model would be a person. So and we could say that the attributes of that model, our name, age, address and social security number and those would be the columns in that table

02:22

and attributes are data that belongs to the model or qualities of the model.

02:29

So These are some examples off models or tables that we could have in our application. I've seen some of these models and other applications so we could have a note table.

02:38

It's common for applications to allow users to place notes on various models. That's why we have the type here that's actually part of a the an idea called polymorphic

02:47

relationship. So, for example, let's say you have a you want affiliate notes to persons and states.

02:55

So when the notes related to estate, you would just put the word state here for that column value.

03:00

And when it's person you just put a person for that type

03:04

went in that column when it's ah

03:07

for that model. Now, the reason you do that it's so that you don't have to have multiple note tables. For example, you would have ah person notes, table and estate notes stable. It could be, ah, more tables you get. Generally, the more complicated the application gets. So you try to, you know, keep it simple when you can. Another example of model might be states

03:27

we have, ah, you know, 50 states, United States. Maybe

03:30

you have a table that's called States and each record is a state, and you have there Bridget abbreviation, their capital city and their name for attributes. Now these attributes can vary wildly. One applications person model might be very different from another applications, and more or less comes down to what that application is trying to achieve

03:50

as its end goal.

03:52

What service it's trying to provide to the users

03:55

again after groups are data that belongs to the model or qualities of the model.

04:00

The ah,

04:02

A note on attributes. A common mistake for those new to database program is to turn attributes into their own tables and models. Now, what would an example of that be? Well,

04:15

let's say you have the person's table

04:17

and now you have this new requirement or this idea

04:21

that a person could be employed or unemployed.

04:26

Well, there's two ways to ah, handle that

04:29

or that I have seen people address that kind of situation, and one, we might be that you make an employed persons table and you make an unemployed person's table.

04:38

Now you have two models off persons with one

04:42

very small difference, and that is one represents employed persons and one represents unemployed persons now, instead of doing that,

04:49

much easier approach would be simply to add.

04:54

And some of you might be thinking, Well, yeah, of course. But you know, I've seen

04:57

I've seen folks do these kind of things

05:00

is at unemployed field

05:02

and just, you know, make it false or true

05:06

for the value. When you add a record, now we can look at this person and tell if he's employed. We didn't need to make another table like that.

05:15

You know, another ah area where you might see that kind of ideas transactions. Maybe you have direct payments and in direct payments or

05:23

direct revenue and indirect revenue. And instead of making each one its own table, making it an attribute for that model.

05:30

Uh, so what is the model? Well, if you look at one of the databases that we were using previously, let's look at the employees.

05:38

Employees is a model. Salaries is a model.

05:43

Titles is a model,

05:46

and if you can see the same approach, an axiomatic it too, which is a

05:50

A data, any RP database. So you have the account model, you have the address model.

05:58

You know you have the

06:00

a bunch of different models carry your model.

06:03

Now there's other tables, and they're the serve, different purposes. But you can see that they've used the idea of models in their design.

06:12

So that brings this lesson to a close. Just to recap, we're going to use a

06:16

simple derivative of the model view controller designed pattern. But we're not gonna worry about control or the view. We're just gonna worry about the model.

06:24

We're gonna use this idea of models to create

06:28

our skim A based on the requirements we get in the next lesson. And we're gonna identify