Recapping Controllers and Views 0:00At this point, we've already reviewed the basics of Vues and controllers. For a quick recap, think of your controllers as the application logic. Or here's an even easier way to think about it. The controller receives requests and returns responses. So in that light, I sometimes think of controllers as coaches. They handle the process of responding to HTTP requests, perhaps requesting some kind of data, and then they return a response. Now when this response is returned, the associated data is handed off to a Vue. And in most modern frameworks these days, even though it doesn't 100% adhere to the traditional academic view of MVC, well, these days we treat the Vue very much like a template. Introducing the Model Layer 0:35And in most modern frameworks these days, even though it doesn't 100% adhere to the traditional academic view of MVC, well, these days we treat the Vue very much like a template. But now we come to models. And you know what? This is going to be very confusing for you at first, and that's because there's a lot of ways to approach this. And if you research it online, there's going to be a lot of different viewpoints. Now in my opinion, one reason for this confusion is because people are taught to think of a model as a single object or a single entity. So as a result, they hear things like fat model, skinny controller, and they assumemodel as a single object or a single entity. So as a result, they hear things like fat model, skinny controller, and they assume they just need to fill up this model as large as it needs to be in order to fulfill their domain logic. And this is a really bad idea. And in fact, that whole term, fat model, skinny controller, I hate that. It's rooted in a basic good idea, which means you don't want your controller to get too bloated, so to speak. And we'll cover that more in future lessons. However, at the same time, you don't want your model to be too bloated as well.And we'll cover that more in future lessons. However, at the same time, you don't want your model to be too bloated as well. So here's a better way to think of it. Instead of a model referencing a single file, think of it more as a layer. But before we continue on, what exactly is a model? Well, if you were to look at something like user.php that's included with every install of Laravel, if you look over it, you might be forgiven for thinking, oh, the model is simply the representation for the data in our database. And that's simply not true. Here's how I like to think of the model layer. Models as Domain Knowledge 2:08And that's simply not true. Here's how I like to think of the model layer. I think of it as one word, knowledge. Everything related to the knowledge of our domain should be placed within the model layer. And that doesn't mean you create a file like user.php and throw everything under the sun in there. Don't do that. Instead, think of your model layer very much like your domain. So for example, at laracast.com, I need a way to bill subscribers. Well, I don't throw my billing logic into user.php.So for example, at laracast.com, I need a way to bill subscribers. Well, I don't throw my billing logic into user.php. Instead, I have a dedicated billing class that I use. Now I also have needs to make various cURL requests, but once again, I don't place it within, for example, user.php. I have a class dedicated to that. So an easy way to determine where to place this various code is to think in terms of responsibility. Is it the user class's responsibility to bill a user? No, it's not. Using Nouns for Models 3:02Is it the user class's responsibility to bill a user? No, it's not. So that should be extracted to its own class and its own responsibility. Now having said all of that though, I think I'm getting a little ahead of myself. This is a fairly large topic and it can be a little overwhelming at first, especially where you are in your learning. So for now, we're going to take a bit of a shortcut. I want you to think of the files that you place within your models directory as nouns. So for instance, at Laracast, well, I need the representation for a lesson, a user, a comment, an episode, and even things like a report. Eloquent ORM Basics 3:30So for instance, at Laracast, well, I need the representation for a lesson, a user, a comment, an episode, and even things like a report. Now in this case, the only class that is included is user. So think of this model, for now at the very least, as the representation for a user of your application. Now what goes along with that? Well, you notice how this user extends a class called Eloquent. Eloquent is what we call an ORM, an object relational mapper. Now that's a bit of jargon that's confusing, but just think of it as a tool that gives us a very easy, intuitive way to query and manipulate the data within our database.Now that's a bit of jargon that's confusing, but just think of it as a tool that gives us a very easy, intuitive way to query and manipulate the data within our database. But once again, I don't want you to equate model to data access layer. It's okay if you kind of think in that way at first, but just remember, the model represents a full layer. It's not a single file. Now to give you an example here, we haven't yet covered databases. We will do that in the next lesson. But imagine that we needed a way to grab all users. For now, to keep things simple, why don't we do it within our routes file?But imagine that we needed a way to grab all users. For now, to keep things simple, why don't we do it within our routes file? Maybe when the user requests users, well, we want to run a function. Now within this callback, we want to grab all users from our database. Well, Laravel provides a user model. So assuming that I have a users table set up, and don't worry, we will do all of that together in the next lesson. But assuming that's all set up, then I could do something like this. We could say, create a variable called users, and we will make that equal to user all. This is the eloquent ORM at work.We could say, create a variable called users, and we will make that equal to user all. This is the eloquent ORM at work. Think of this as an eloquent syntax for what ultimately translates to select star from users. Now it's possible if you are coming from that procedural world, you are used to embedding all of these various SQL queries into your PHP files. But think about it. Why do we want to group all of that stuff together? That just creates muddy, muddy, muddy code. Instead, we can abstract all of that logic so that we can instead say user all.That just creates muddy, muddy, muddy code. Instead, we can abstract all of that logic so that we can instead say user all. Or here's another example. What if we want to find the user within the users table that has an ID of one? Well, with eloquent, we would say user find one. Notice how readable that is. Find the user that has an ID of one. When that data is returned, it will be treated like a class. So that means if you want to, for example, echo out the username, then you could simply return user username or any field you want if you want to grab their email address. Model Layer Takeaways 6:05So that means if you want to, for example, echo out the username, then you could simply return user username or any field you want if you want to grab their email address. Because the returning data will be cast to a class, we can treat it like any other object. OK, and you know what? I don't want to go any further just yet because we would either get too high level or we would be getting ahead of ourselves. For now, just think of your model as not a file, but a layer that represents the knowledge of your application. Or another way to think of this is your model doesn't need to have any understanding whatsoever of HTTP.Or another way to think of this is your model doesn't need to have any understanding whatsoever of HTTP. It doesn't need to understand at all what a request is or how we return responses. So in that light, our domain is our application. It is the heart of our application. But like I said, that's talking at a bit of a higher level than you may be at right now. For now, it's perfectly OK if you think of the various files within your models directory as the representation for a table in your database. That'll get you started, but keep learning more about this stuff and you'll learn aboutas the representation for a table in your database. That'll get you started, but keep learning more about this stuff and you'll learn about better ways to structure your applications.
