0

I have a User model. A user can be reviewed. Thus I also have a Review model that represents a review of the user. With the review a rating of the user is saved.

Let's say I am to create a method that fetches the rating of the user based on all reviews of him, for example the getRating() method. Would I create this method on the User model? Or would you create for example a review-managing service class and include the method in that class?

Adding the getRating() method to the User model feels like a logical thing to do, but on the other hand things might get out of hand at one point, leaving me with a huge User model class.

(This is a simplified example, in reality the reviews can come from multiple sources).

(PS I have read some posts and articles about this, but I cannot find a satisfactory answer to my question).

minitauros
  • 1,920
  • 18
  • 20

2 Answers2

1

You shouldn't have "a User model" and "a Review model". The Model in MVC is your entire core app, it encompasses all data structures, services, database adapters and auxiliary stuff that makes your app work. What you should have is something like:

  • a User business object and a Review business object, purely defining the data structures
  • a UserRepository or UserDAO or UserORM or whatever other paradigm you use to interact with your database which translates data in the database to/from User objects; same for Review
  • a UserService which does things for user related tasks, like storing and retrieving them via the database interface, same for Review, or perhaps some differently named service being responsible for both together

It doesn't all have to map 1:1; a business object instance may map to multiple database tables, which the corresponding *Repository/*DAO/whatever takes care of, and multiple of those may be combined into one service making something useful happen.

The action to retrieve some specific data then belongs into a service.

deceze
  • 510,633
  • 85
  • 743
  • 889
  • My appreciation for a good explained and concise answer, which helps users to have the correct perspective of the model layer. –  Jul 14 '17 at 16:25
  • Agreed, but I find it so hard to remove the concept of database as the model. It's definitely another layer of programming skill. – Tim Morton Jul 14 '17 at 22:56
  • @TimMorton Once you try it it actually makes your code so much simpler, because every individual piece is simpler (if done right), because you're not mushing several responsibilities into one class anymore… – deceze Jul 15 '17 at 08:19
  • @deceze Rather than spamming these comments, I posted a question I hope you'll be interested in: https://stackoverflow.com/questions/45120733/how-to-separate-database-from-model-and-extending-model-over-multiple-tables – Tim Morton Jul 15 '17 at 17:17
0

Why not add the getRating() to the Review Model. The method will accept a User Object or a User Id depending on the logic in the method. The User Model has no business knowing about reviews. My thoughts though.

Tunbola Ogunwande
  • 133
  • 1
  • 5
  • Thanks for your reply! This is because my example is simplified. In reality, the reviews can come from multiple sources, and are thus not only linked to a `Review` model / db record. – minitauros Jul 14 '17 at 12:34
  • 1
    Better to create a Review Service to handle the complex logic then. The method of the service can accept the relevant objects needed to process the logic. – Tunbola Ogunwande Jul 14 '17 at 12:37
  • Though the only object it needs it the `User` model every time. That is why it feels so weird moving these methods from the `User` model to a service class - they only need information about the user, might as well keep them in the `User` model? – minitauros Jul 14 '17 at 12:39
  • I see your point. Its simpler to keep in the User model but in reality since the reviews would probably be fetched from another model/table or from other sources, I would still stick to using a service. What if the method need more objects in the future? It might become messed up. – Tunbola Ogunwande Jul 14 '17 at 12:41
  • Hm I see your point too :). I think that unless someone else provides an answer with another insight, I will just stick with keeping the methods in the `User` model for now, and will move them to a service if the need arises. – minitauros Jul 14 '17 at 12:44