So, I should probably learn the basics of MVC before I try to shoe-horn stuff into what my understanding of it is.
Everything I read generalizes the concepts a bit too much and I end up with a half understanding.
Im not even sure what role the model even plays in the whole thing.
Like, lets have a use case where a user deletes a photo from a photo gallery.
First the user browses the photos determining which one to delete.
In this case, the gallery controller would have a browse case, which it contacts the database and gets the photos for the current page and category or what not.
It would then call the browse view which would display the photos however. What "logic" should be done by the control view? Should it loop through the array of images, parsing the data and displaying it as needed?
So now the user sees all the photos and they click the delete button on one.
That gallery controller would have a function for the delete case.
It would then access the database and delete the row.
It would then call the gallery delete view which would show a message about the successful deletion. Or perhaps it would call the browse view again and show the message there with the newly updated gallery??
Thats the type of stuff I dont get.
Also, I would assume I would want to have a photo object which itself handles the deletion, updating, adding of images to a photo. And perhaps even the display of said photo. How does this fit into the MVC design?
How does ajax fit in? The controller gets an ajax call and then passes the data back to the javascript in JSON for it to manipulate the dom?
Or could you have the controller get an ajax call, then contact the view, serialize the html and pass that back to javascript?
OO Design...understanding MVC (edited)
Moderator: General Moderators
-
ajlisowski
- Forum Newbie
- Posts: 22
- Joined: Wed Dec 16, 2009 8:22 pm
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
Re: OO Design...understanding MVC (edited)
First, please use paragraphs. You post is a little difficult to read. I know it is often difficult to think about your problem and write about it.
WIth MVC, start with the Models -- they are your application. If you have a gallery then the first thing you should do is create a Gallery Model class. That class should provide the functionality for the gallery. The Controller then gets Requests from the user asking for specific things from the Gallery. The View takes the data from the Gallery that the users asked for (and some info from the Controller) and wraps it in HTML to send back to the browser.
MVC is a high-level design pattern that solves some high-level problems. On of the difficulties in understanding MVC is that you need to have the problems it solves before it is real to you. Implementing MVC will use many other design patterns in the process.ajlisowski wrote:So, I should probably learn the basics of MVC before I try to shoe-horn stuff into what my understanding of it is. Everything I read generalizes the concepts a bit too much and I end up with a half understanding.
You recognize your big problem -- that you do not understand the Model. And you quickly go astray by putting everything in the Controller.ajlisowski wrote:Im not even sure what role the model even plays in the whole thing. Like, lets have a use case where a user deletes a photo from a photo gallery. First the user browses the photos determining which one to delete. In this case, the gallery controller would have a browse case, which it contacts the database and gets the photos for the current page and category or what not.
WIth MVC, start with the Models -- they are your application. If you have a gallery then the first thing you should do is create a Gallery Model class. That class should provide the functionality for the gallery. The Controller then gets Requests from the user asking for specific things from the Gallery. The View takes the data from the Gallery that the users asked for (and some info from the Controller) and wraps it in HTML to send back to the browser.
(#10850)
Re: OO Design...understanding MVC (edited)
A model is like a real world model. When we build a model car we build a small, model of it. Maybe the doors open & close because we are modeling that part. If we were modeling something else maybe the car would move kinetically forward, but the doors would be fixed. So a model is just that, you're making a "model" that is a simplified version of a real world "thing".
In MVC your models are objects, allowing you to have many instances of those models, and re-use those models in various controllers (use cases) and applications.
When we talk about the "view" its easier to think about a grid of numerical data, you could present that as various types of bar, pie charts, tables, etc.. (all different "views" of that data, or "model")
In your example the controller may look like this:
The view for this action may just be a success message. In a real app you might have a security check as well, in the controller. All the logic related to deleting is NOT in the controller, and NOT in the view. The controller reads like Plain English (or as close as you can get)
In MVC your models are objects, allowing you to have many instances of those models, and re-use those models in various controllers (use cases) and applications.
When we talk about the "view" its easier to think about a grid of numerical data, you could present that as various types of bar, pie charts, tables, etc.. (all different "views" of that data, or "model")
In your example the controller may look like this:
Code: Select all
class Controller {
function delete($id) {
$model = $this->findGalleryItem($id);
$model->delete();
}
}