0

Due to these answers, I've decided to implement MVC (or a variation of it) into my application. But the more I read the more confused about this topic I get. Some people say the business logic belongs to the model, some say the model should only holds data/a state, some say the logic should be entirely in the controller class(es), and for others the controllers are just the glue between the model and the view to display the information the model holds.

In my specific application, the process I want to put into an MVC pattern can generally be divided into these parts:

  1. Retrieve information from the web server
  2. Interpret/Parse that information and store it in variables
  3. Take those variables and display them.

I can seperate these processes, but they are not exactly what an MVC pattern should look like. I'm not even sure if I can apply the MVC pattern here. There is no real persistent data in the application, only the variables where the parsed things are stored. MVC mentions nothing of retrieving or interpreting the data. Have I overlooked something or do I just need a different pattern here?

Namnodorel
  • 242
  • 1
  • 3
  • 10
  • But on the other hand, _every class should only have one reason to change_, and the model class(es) would have multiple reasons to do so. – Namnodorel Nov 27 '16 at 12:55

1 Answers1

3

Have I overlooked something or do I just need a different pattern here?

Why do you feel the need to fit this into a pattern? Yes, MVC is a pattern, and it has a lot of variants.

MVC, MVP, MVVM, MD, etc. People have this tendency to split hairs and try to identify similarities and differences between them, trying to fit their application on top of one pattern or another, so much so that now you have MVW (ModelView"Whatever works for you").

All of these patterns are about one thing and one thing only: separation of concerns. This is what you need to follow first and your solution will naturally fit into one of the patterns above, or maybe none at all. Look at SOLID and SRP too.

Yes, it's good to know these patterns and see what problems they solve and how they solve them. Later, with that knowledge, you can recognize if some application can benefit from one or the other. But don't try to force your solution onto one of them. The point is how (in this case) MVC can help you build a better application, not how you can write your application to respect MVC.

Bogdan
  • 3,600
  • 10
  • 13