MVC - what methods should be in the model class except for set / get elements?

Question

Methods that do manipulations with member classes of a class should be implemented on the model or in the controller? It depends on how "heavy" this manipulation is.

"manipulation" I mean - get a member of the class, do a long calculation, which is based on it, and then return another value related to this class.

For example, having a Board class that contains a cell matrix element, now I want to implement a method that returns all surrounding cells in accordance with a specific cell. Who is responsible for the implementation of the foregoing?

If this question relates to another stack verification protocol, he will be ready to send a message.

Answer 1

What you call a "model" is actually a domain object . The actual model in MVC is just a layer, not a specific thing.

In your specific example, Board should have a method that returns this list. I assume that you actually acquire it, because then you need to continue interacting with these cells.

It uses services within the model level. If you use them, they are the external part of the model layer and contain the application logic - the interaction between different domain objects and the interaction between persistence (usually either data mappers or units of work ) and domain objects.

Say you make a game, and you and the player carry out an AoE attack. The controller takes care of the service that is responsible for this functionality and sends a command: this player has aimed the AoE in this direction by completing it.

The service creates an instance of the Board and requests the surrounding cells of the target location. He then performs “damage” in each cell of the collection that he acquired. Once the logic is complete, it tells the Unit of Work instance to make all the changes that occurred on the Board .

The controller does not care about the details of what the service does. And he should not receive any feedback. When execution moves to the view, it requests the latest changes from the model level and changes the user interface. Since the added benefits - services allow you to stop the business logic from leaking at the presentation level (mainly from controller views).

A domain object should contain only methods related to their state.

Answer 2

Keep controllers in the worst state, don't let them do a lot, this is consistent with the principle of shared responsibility in SOLID for object-oriented design. If you have fat controllers, they are difficult to check and maintain.

As for the models, I had dumb models before they did nothing but match the database tables, and this was inspired by most of the sample applications that you see on the Internet, but now I do not.

I (try) to follow the principles from Domain Driven Design, where models (entities in DDD terms) are at the center of the application, they are expected to encapsulate the behavior associated with the object, they are smart models (so yes, the logic associated with the object will be live with him in this case). DDD is a much more serious topic, and it is not directly related to MVC, but the principles underlying it help you to better develop your applications, there are many materials and sample applications available on Google DDD.

In addition, the Ruby On Rails community, which seems to inspire most MVC infrastructures, also seems to be pondering around Fat Models and Skinny Controllers.

In addition, you can add View Models to your mix, which will be useful to me. In this case, you can have a ViewModel to represent a dumb subset of your model (s), just used to create a view, it simplifies your life and further separates your views from your models so that they do not affect your design decisions unnecessarily.

Answer 3

I think this has little to do with MVC and is much more related to conventional software development.

I personally would not hesitate to adhere to trivial calculations in the model, but I would be extremely careful about fat models.

Now, the fact that MVC stands for Model View Controller does not necessarily mean that everything should be either a view, or a model, or a controller. If you feel the need to transfer responsibilities to a separate class that doesn’t really qualify as M, V, or C, I don’t understand why you shouldn't.

How you implement it is up to you. You can use this separate class as a “top-level” object (due to the lack of a better term) or create a model delegate method for it to hide the fact that you are using it. I will probably go after the last one.

Everything is debatable, though. Everyone and their sisters seem to have a different opinion on how to do MVC correctly.

I, I just think it's a guideline. Of course, this is a great idea, because it leads you to a better separation of anxiety, but in the end - as always happens - there is no single way to use it, and you should not limit it excessively, to the point where everything should be either a representation or model or controller.

Answer 4

In accordance with best practice, we should use properties for computed fields with access only to access. example public double TotalCost {get {return this.Role.Cost * TotalHour; }}