In proper MVC, should everything be a model, view or controller?

Question

Something that I was interested in, but somewhat embarrassed to ask so far: in the "correct" MVC (strictly adhering to the template) should everything be a model, view or controller? If not, can you give an example of when a template break is appropriate or necessary? Finally, what is the role of class methods (or static) in MVC?

Case study: I ​​have OneModel and TwoModel . There is no natural reason to think that they are inherited from any superclass. Both have completely different properties, but they share the emailAddress field, and I want validateEmailAddress() for each model sometimes. I do not want to copy the verification code in each model, so I am making the ValidationHelper class with the validateEmailAddress(String emailAddress) class method, which I will now call in each of OneModel and TwoModel .

Did I break the pattern? How can i fix this?

Answer 1

If you see Model, View, and Controller as application layers, and not just presentation-level components, then your email validation class will be part of the model layer because it contains business logic. I don’t see where you are breaking the pattern, and not every model class should be a data object.

The problem with “strictly sticking to the pattern” is that the pattern has evolved over time. The original template was designed for single-user GUI applications. It was later adapted for the Internet, but with different interpretations, especially regarding responsibility between the model and the controller, as well as between the client and server. Therefore, prepare for different answers without a single "true."

Answer 2

The MVC design pattern consists of two main parts:

• presentation level
• model layer

The presentation layer provides users with the ability to interact with the model layer, while the model layer contains all the business logic and its associated task.

A model is not a class or object. Instead, it contains several groups of structures, each of which has a different aspect of the domain’s business logic as its responsibility. You can read a longer explanation here .

The presentation layer is mainly divided based on how it interacts with the model layer. We can say that the controllers "write" at the model level (through services) and see the "read".

The simplest part of the entire MVC design pattern (and other MVC-based patterns) should be the controller. They take user input and are based on this change in the state of the model layer. They can also change views, but when MVC is applied to the network, this is the exception rather than the rule.

As for the views - I'm still trying to understand them. What I just got can be read here.

_{Note. There is a serious lack of material for implementing views when they are applied to the Web. Since the platform is completely different compared to desktop applications, it is impossible to directly transform the same recommendations. And I did not find any wireframe related materials on this subject that focused on creating views for the Web.}

Answer 3

You must understand that MVC is an architectural pattern . So this is a higher level template that describes how your components are organized and interact with each other. To achieve this organization, you will need a set of specialized components that will do the dirty work for you. In this set, you will probably have some components that do not meet the definition of any MVC letter, some components simply help functions, others on the interface between layers, working on their integration.

So, the answer is no , not all - it's a model, view, or controller.