1

I'm designing a system at the moment using MVC (with Laravel, if that matters) and I'm trying to decide how best to architect a part of it.

An an analogy, you could look at it like this:

There's blog posts, and each blog post can have three different types of comments. Each type of comment is completely different from the other, and it viewed on a separate page.

So for example, let's say one comment type is plain text. There would be a plain text page where all the plain text comments for that blog could be viewed, edited, created, etc.

There's another another type of comment type called Twitter. There would be a separate page where all Tweets posted to that blog post could be viewed, edited, created, etc.

And so on.

My first instinct was to try and shoe-horn all these different types of comments into one CommentController with a Comment Model, and then read the CommentType and process them appropriately, saving them into the corresponding table for that CommentType, showing the right form for that CommentType, etc.

But would it be better practice to have a different CommentController and Model for each type? I.e. PlainTextCommentController/PlainTextComment Model, and TwitterCommentController/TwitterComment Model?

Part of me feels that's bad practice, because it seems so inefficient, but I can't deny it would improve readability of the code.

Maybe it doesn't need to be optimized to cleverly use one Controller, trying to give it responsibility for every comment type. Maybe it just would be better to split everything out, cleanly and clearly?

Would it not be bad practice to do that?

  • 1
    If you just aim for Single Responsibility Principle, you won't regret it! Small, focused controllers, models will help you in the long run as a basic programming principle. It's hard to tell others than these since your domain language shall drive the overall architecture. – kayess Jun 21 '17 at 14:32
  • @kayess Yes. Must keep SOLID in mind! (Although in my head, they were all grouped until one thing: Comment, but clearly that's not quite true.) – Django Reinhardt Jun 21 '17 at 14:36
4

I would not fault you for having three different controllers; there is absolutely nothing wrong with that.

However, if you are feeling the need put each comment type in its own controller, there is a good chance your controller(s) are doing way too much work!

Each action in a controller should only be a few lines, just wiring things up and directing the flow of the application. Controller actions should not be doing any heavy lifting, but rather are responsible for delegation.

Each comment type should have its own comment domain class, shared functionality/properties expressed with only interfaces.

Each comment class should also have its own separate repository class which is responsible for saving/reading from the DB.

Each type of comment should have its own view model and view.

After you have refactored all the business logic and DB logic out of the controllers, whether or not the three comment types share a controller or not should be a moot point.

| improve this answer | |
-1

Within the MVC design pattern (and the other related MV* patterns), there is only ever one (domain) Model, although there can be many ViewModels if you have them.

The domain Model contains all the application logic that is not part of the user interface and can consist of as many classes as you need to model the application behavior.

There should be a View for every screen and/or re-usable portion of a screen.

And finally, the Controllers tie the domain Model and the Views together.

With that in mind, Controllers and domain Model classes don't have corresponding counterparts, except by accident or in a very simplified design. It is far more logical if there is a correspondence between Controllers and Views, or Controllers and interactions that can be made.

In simple CRUD applications, with no application logic more complex than storing are regurgitating what the user entered, that last correlation of Controllers to interactions can quickly start to look like a correspondence between Controllers and Model classes, but should not be interpreted as such.


To determine how many Controllers you need for the various Comment types, you should first create your domain model without any consideration for what the UI looks like. After that, you can think of what kind of interaction the user would have with each type of Comment and if they are all similar enough to handle in one Controller or that they should get different Controllers. One consideration here is also if a single Controller would be able to perform common tasks on Comment instances without knowing what type of Comment it is actually interacting with.

| improve this answer | |
  • 2
    The domain/application model, sure, but a view model is usually specific to the view? – jleach Jun 21 '17 at 15:57
  • 1
    In more complex applications, you will have trouble reusing a single domain model as a view model. Domain models can sometimes be used as view models, but view models should never be used as domain models. – TheCatWhisperer Jun 21 '17 at 16:06
  • @jdl134679: Where does the MVC pattern describe view models? But yes, if you have view models (typically if you follow MVVM), there will be multiple of those. – Bart van Ingen Schenau Jun 22 '17 at 16:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.