1

Using the Laravel PHP framework, I'm wondering about the design of resource controllers, where you define a new controller for an individual entity, say, "project" or "article", and then provide methods based on the different CRUD operations.

In the context of my application, I feel like I get more utility by having a controller for each CRUD operation itself - say, "UploadController" - which is then responsible for handling that operation for every entity that needs it. This allows me to share tasks like validation between similar entities, and I don't have to include operations (say, Update) for entities that don't need them. It also lets me call a single controller for pages where I'm creating many different kinds of entities at once, such as generating a hierarchy of entries like project->subproject->article all from one form.

But am I missing some huge disadvantage to this? Why is the controller=entity & method=verb structure so popular, vs controller=verb & method=entity?

Luciasar
  • 393
  • 3
  • 7
  • 21

1 Answers1

3

You can, but I wouldn't recommend it.

One of the major "features" of object oriented programming is encapsulation. It means that each object should have access to the least possible, and the most specific, variables, and shouldn't have direct access to data that is not directly related to it.

Moreover, object-oriented programming is meant to be easily maintainable, even by somebody that didn't design your application.

Doing your "verb-based" controllers would result in an object managing article data, tutorial data, member data, comment data, etc... It would be a mess, and would make no sense in an "object" design.

Specifically for Laravel, you have one class by entity type (which is used for the ORM, etc...), it's logical to have one controller by entity type too.

The routing also corresponds to an entity-based system : you have /posts/create and /comments/edit/42, not /create/posts or /edit/comments/42.

And from a pure "aesthetic" standpoint, I'd rather go with 30 controllers having 4 methods than 4 controllers having 30 methods. Much easier to read, much easier to maintain.

Luciasar
  • 393
  • 3
  • 7
  • 21
AntoineB
  • 4,535
  • 5
  • 28
  • 61
  • Ok, that makes sense. But I'm still struggling with how I can do some common tasks cleanly, such as not needing to copy-paste my validation code so much, and do that grouped data entry I mentioned. Would I just have a separate "submission controller" that would call all the individual entry controllers to do that? – Luciasar Jul 24 '15 at 19:36
  • You could do a "validate" method on your entity class that would take the inputs and return the validator state. I think it would avoid code duplication and follow a good entity-based design. – AntoineB Jul 24 '15 at 19:41
  • How about the grouped data entry? I was kind of put off by the idea of having to call 4 different controllers just to deal with a single form. Is there a better way of handling that as well? – Luciasar Jul 24 '15 at 20:03