Cardinality of MVC on desktop

Question

What should be the cardinality of the desktop MVC?

Models: typically one, there may be more.

Views: how many are observing the model, or a tree, representing approximately the GUI? Vision should follow the Composite pattern?

Controllers: one, or one for each Model, or one for each View?

Or other values?

Answer 1

The idea of MVC is just not to be one for one. Many problems, many of them are so, so it is clear that MVC should not be used.

It’s not that I can’t, but you can do something simpler with that cardinality. A common mistake in most web projects is that people make MVC because they said it’s right, but they didn’t say how to use it, so one adopts it as a cake recipe for everything. On desktop maybe miss less because it is rare to use this pattern.

His idea is that views should be able to call which actions of which controllers will, and a controller can trigger the views that are necessary.

An action can be triggered by something other than a view defined in the system. It has action that does not trigger a view (I don’t know if desktop occurs).

In some cases it is possible that in fact a view may be related to a controller, but it is pure organization and should not be mandatory. I say this even because in theory you could have a controller for each action and nothing actually changes to the system, or to have a single controller with all the actions of the entire system. Project organization has nothing to do with the pattern. Each project asks for something different. Action is something more important than the controller.

And it’s common to have certain orthogonality among them.

A controller should be able to access all the models they want, because the processes are complex and have a lot of related things. There should be a 1:1 ratio except by coincidence. And it is not uncommon that it generate model views for vision to consume.

I disagree that there should be only one model. There is one question that talks about it, but I didn’t find it (anyone?). There is even something that can be called a The model in the sense of having all the modeling of the system, but each object is a model, so for me you have several models always. Note that if there was only one model the question would be wrong in the part that relates to controller.

I’m not sure I quite understand the part about view. But I can assure you that the need for screens must decide what the demands are, not other things. It seems Composite has no direct connection, but I may have missed something.

Just as the templates should be created according to the needs of the objects (business). They are different needs.

Controllers should ideally exist according to the need for clustering of related actions, and these should exist as long as there are clear processes that must be triggered.

Maybe he wanted to talk about organizing the project. That doesn’t help much, and it’s like OOP, there’s no rule that you decorate and everything looks beautiful, you have to know how to ride in a way that makes sense, and it’s hard to hit something that’s complex.

Let me give you an example. Is vendor commission control part of sales or financial? The answer is more complicated than it seems and only those who understand the subject can answer well. Neither? Is it separate? But it’s only triggered when there’s a sale and when there’s a receipt.

MVC on desktop

I’ve never seen a good desktop MVC system (might exist). Desktop is frontend. I recently saw some of the best specialists of frontend say that MVC in browser doesn’t make sense, only goes to the backend. I did not go into the subject, but it seemed to make sense and I heard from people who are not braggarts. If that’s true, why would it be good for the desktop?

MVP, HMVC, MVVM, and other such things is not the same as MVC.

I don’t have a definitive answer yet and that’s the best answer I can give, even if some people don’t like it because they always want the ultimate truth.

Maybe made sense for the desktop to be 1:1, and then it would be right that it should not be used in that kind of technology.

1:1 is good for CRUD. CRUD doesn’t need MVC. #I said.

I admit there may be another vision for this.

I understand that some people have gotten so used to doing so that it’s easier for them to always use MVC, up to where they don’t need it, but that’s taste and not engineering (and no problem at for taste in front when it makes sense).

When you start automating certain things or having V contact with M, is it still MVC? There are those who say you can, others who can’t, so I understand nothing.

I’ve seen so much out there, it’s hard to say what’s right. And I always say that if you have a lot of different opinions about something, it’s not a good thing. And a lot of people will read this and say that you know what’s right, but each one’s right is different, because his is right, just because it’s what he learned?

And there’s one thing originally, but is it what people use? If they use it differently, why do you call it MVC? The same problem of people calling OOP what is not?

Some sources are so bad they call it Pattern design.

Related (maybe I update): How the MVC framework works for Desktop applications?.