0

As part of a university project I'm developing a web application in PHP and trying to follow MVC principles as much as possible. I'm not using an off-the-shelf framework because I want as much of the project to be my work as possible to help get a higher mark.

To delete an item (each item has an id, status, title, parent_id) from a database I go do the following process....

  • User hits a delete button and is asked to confirm
  • When clicking confirmed a "page" loads which calls the controller, initiates a model which is stored in the controller object
  • A method in the model object is called to load the item from the database based on the ID in the URL
  • I edit a status property in the model to mark the item as deleted
  • I then save the model to the database which in effect deletes it.

I also want to delete all child items in the database of the item that has just been deleted. Where is the best place to do this? In the the controller? In a separate functions file? In a model file?

I'm pretty new to the whole MVC idea, so any help / advice is much appreciated.

gbuckingham89
  • 377
  • 2
  • 14
  • 2
    Deleting related records of a model when that model is deleted is an implementation detail that should be done in the model and hidden from the controller. This is the kind of thing that models are explicitly for, and the biggest reason you'd want to distil this logic out into a model layer. – user229044 Nov 14 '11 at 16:00
  • 1
    Or create a database relationship with a ON DELETE CASCADE. (That's what I usually do). Although this is not very MVC :P – mobius Nov 14 '11 at 16:02

3 Answers3

3

The basic breakdown of MVC is

  • Model: Business logic
  • View: Presentation logic
  • Controller: Glue logic (triggers model functionality based on user input, render views based on model output).

The statement "Deleting an item will cause all its children to also be deleted" is a description of something that needs to happen in the business logic. Therefore, it belongs in the model.

Implementation is up to how you have implemented getting child items and deleting items in your model, but it will typically consist of getting a collection of your model's children in its delete method, and invoking the delete method for each child in the collection (each child will also look for children and delete them when this happens). Now the view and controller don't have to worry about whether or not a model has children, as it's all taken care of in the model's business logic.

GordonM
  • 31,179
  • 15
  • 87
  • 129
1

Part of being a good developer is knowing when not to reinvent the wheel. And this is certainly one of those situations. I suggest you first ask your professor(s) whether you are allowed to use an off-the-shelf framework or not. This "I want as much of the project to be my work" is pretty much nonsense. If you really want it to be your own work, do it in assembler :).

If you still have to write everything from scratch (in PHP), I suggest you first look at well-established MVC frameworks (e.g. Symfony), in order to get the feel of how such a framework should work. Maybe have a look at the source code, too.

Felix
  • 88,392
  • 43
  • 149
  • 167
  • 3
    Sorry, but I disagree with your point of (not not) using a framework. I'd first get a basic knowledge of how to write an mvc based application and then use a framework. Otherwise you'd be lost by all the opportunities to manage an application. I remember me using Zend the first time, it was embarrasing. Although I had a basic knowledge of how mvc worked, it took me a week or so to get into the framework. – mAu Nov 14 '11 at 16:14
  • The not inventing the wheel comment is a good point. However, it doesn't answer the question, which was "Where should deleting children be done?" – GordonM Nov 14 '11 at 16:18
  • @mAu 1 week for a framework is a decent learning curve. 1 week for **your first ever** framework is actually laudable. Also, how do you get basic knowledge of how to write an MVC-based app without using an MVC framework? Write it yourself? How are you supposed to know how it should work? I work in RoR and before starting that I had some idea of what MVC is, but it seemed really vague. Actually getting down and dirty with RoR turned my world upside down and I finally understood what the MVC pattern **really** means. – Felix Nov 14 '11 at 16:23
  • 1
    Usually this is certainly a good advice, but university is not here for just solving problems, it is here for understanding something at a much higher level. Let's say he solves that using a framework which is great now, by the time he graduated this framework will be obsolete, and so is his knowledge. – duedl0r Nov 14 '11 at 16:28
  • @duedl0r don't be so certain it will be obsolete (why would it?). Also, what matters is not the fact that he learns a particular framework, but the fact that he properly understands the concepts of the MVC pattern. And the best way to do that, IMO, is by using an established framework. Also, if I had a nickle for every time I learned something deprecated by at least ten years in university... – Felix Nov 14 '11 at 16:31
  • I knew the issue of not choosing to use a framework would come up. As duedl0r mentioned, it is also about the learning curve - it's very well being able to read documentation and use a framework, but I'd prefer to know exactly what is happening and how it's doing it. I guess I also just prefer to have everything under my control, functioning the way I want it to. – gbuckingham89 Nov 14 '11 at 17:04
  • @Felix: Learned and understood it by reading books. And yes, one week is not much, but one week for grasping the first bit of the whole system should be enough. – mAu Nov 14 '11 at 21:27
1

I would probably do that outside the PHP MVC pattern. Using MySQL innoDB tables you can achieve that using Foreign Keys:

CREATE TABLE parent (id INT NOT NULL,
                     PRIMARY KEY (id)
) ENGINE=INNODB;
CREATE TABLE child (id INT, parent_id INT,
                    INDEX par_ind (parent_id),
                    FOREIGN KEY (parent_id) REFERENCES parent(id)
                      ON DELETE CASCADE
) ENGINE=INNODB;
SERPRO
  • 10,015
  • 8
  • 46
  • 63
  • Thanks for this, I should have mentioned I'd prefer to keep as much as possible in the PHP rather than SQL - knowing me I would forget the SQL was there. This will be useful for something else I'm working on though! – gbuckingham89 Nov 14 '11 at 17:05
  • You're welcome. If you keep all the logic in PHP then you should do what GordonM said and put that in the Model – SERPRO Nov 15 '11 at 09:57