2

I am making a web app with Laravel 4 and in this app I have some articles. Each article has multiple Images. Now, when I want to delete one article, I also have to delete the imagse belonging to the article. I am wondering, where I should put the Image delete method. I could put it in the article controller, the image controller or the image model.

Since I also have to be able to delete Images individually without touching the article, it wouldn´t make sense to have the article controller delete the files. So where to put it? Image model or Images controller? I think Image Model.

Edit: I use the Laravel ORM and all articles are linked to their images. Deleting one article also deletes all images from DB. I was just wondering, where the delete from filesystem should go..

Kris
  • 768
  • 1
  • 8
  • 19

3 Answers3

4

First and foremost, the model is a layer. It's not pluralised - you can read more about this here: php - How should a model be structured in MVC?.

If you are using a MySQL database, you could look at ON CASCADE DELETE - which would delete all images in the database related to the article. If you didn't want to do this on the db side, you could be looking at the Entity\Repository pattern, and this can readily be achieved through the use of an ORM like Doctrine. This would allow you to annotate your "Entities" (domain objects with class members, properties and a few getters/setters) for a php-side version of ON CASCADE DELETE.

Your controllers should be doing no business logic. Do this in your model layer - meaning your controller will only call methods and get the responses from the model layer.

In conclusion, link your articles and images (entities) either in the db or via an ORM's annotations (doctrine, for example), so that when you delete one, the others are deleted for you.

Finally, if that's too much for you, put code to delete the images in the same file as you perform the deletion (repository) of the article (entity).


Addition: If the image paths aren't stored in the DB, and you literally want to delete a physical file, you should be writing an external service (class) with the Single Responsibility of handling the file deletions. The code that deletes the article will then call out to this service. It means your code will be more testable, and you can throw custom exceptions to determine that something went wrong (like an image couldn't be deleted).

Community
  • 1
  • 1
Jimbo
  • 25,790
  • 15
  • 86
  • 131
1

ImageModel would be the right place. Add a delete method to your ArticleModel in which it will loop over all related images, call the delete method and afterwards delete itself.

<?php 
    class ArticleModel {
        public function getImages() {
            //fetch your images
            return $images;
        }

        public function delete() {
            foreach($this->getImages() as $image) {
                $image->delete();
            }
            $this->delete();
        }
Tobias Golbs
  • 4,586
  • 3
  • 28
  • 49
0

It totally depends on you and your application.

There are those who go for skinny model, fat controller and vice versa. There are also people who would put things like that in a library, although most apps don't require that extra layer of seperation.

I think sometimes programmers spend more time thinking about where to put code than actually writing code.

I know seperation needs to exist for code readability etc, but often anything more than seperation of workings and display logic is overkill. My 2 penneths anyway.

My personal opinion. Skinny controller. Let it bounce traffic around, nothing more. Anything like that should be in your model or if you have to a library.