5.1 Design Pattern MVC
Join over 3 million cybersecurity professionals advancing their career
Sign up with
Required fields are marked with an *
Already have an account? Sign In »
7 hours 36 minutes
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
in this lesson, we're gonna discuss the approach were run to take when developing the skimmer for our application.
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
And the one that we're going to be looking at is model view controller. In fact, we're more concerned with the model,
So this is gonna be even easier for us
because we're gonna be concerned with the model which is in the database. We're not really gonna be concerned with the view
or the controller,
so that would make it a little bit easier for us. So why aren't we concerned with this? Well, because this is actually
ah, part of full stack development. So we were doing full stack development. We would be concerned with every part of this idea,
but right now we are strictly focused on the database or sequel.
Now the view and the controller would typically exist an application code. So that would be the PHP frameworks, like Clarabell or
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.
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.
So what is a model? Well, it's it's basically a noun, so it's a person, place or thing.
and model is also a table in a database.
I'm going to quote that out so it doesn't turn
that color on me.
So, for example, we could have a model or table called persons,
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
and attributes are data that belongs to the model or qualities of the model.
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.
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
relationship. So, for example, let's say you have a you want affiliate notes to persons and states.
So when the notes related to estate, you would just put the word state here for that column value.
And when it's person you just put a person for that type
went in that column when it's ah
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
we have, ah, you know, 50 states, United States. Maybe
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
as its end goal.
What service it's trying to provide to the users
again after groups are data that belongs to the model or qualities of the model.
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,
let's say you have the person's table
and now you have this new requirement or this idea
that a person could be employed or unemployed.
Well, there's two ways to ah, handle that
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.
Now you have two models off persons with one
very small difference, and that is one represents employed persons and one represents unemployed persons now, instead of doing that,
much easier approach would be simply to add.
And some of you might be thinking, Well, yeah, of course. But you know, I've seen
I've seen folks do these kind of things
is at unemployed field
and just, you know, make it false or true
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.
You know, another ah area where you might see that kind of ideas transactions. Maybe you have direct payments and in direct payments or
direct revenue and indirect revenue. And instead of making each one its own table, making it an attribute for that model.
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.
Employees is a model. Salaries is a model.
Titles is a model,
and if you can see the same approach, an axiomatic it too, which is a
A data, any RP database. So you have the account model, you have the address model.
You know you have the
a bunch of different models carry your model.
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.
So that brings this lesson to a close. Just to recap, we're going to use a
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.
We're gonna use this idea of models to create
our skim A based on the requirements we get in the next lesson. And we're gonna identify
one models we need, what relationships between those models we need. And we're gonna create a nice schema that would power an application of the type that will be described the next lesson. Anyways, I hope you enjoy this lesson. And I look forward to working with you throughout this module. See you in the next one. Thank you. Bye.