Model vs. Controller

[Midnight Modding]

A lot of times I end up undecided whether various methods are best to be put into the model or the controller.

For instance, forms. For specific ones that ip.suite has helpful methods for, I use the model, such as node forms and content item forms.

For other forms, I kind of go back and forth on what would be best. Typically, if I am going to use a form for both the front end and the acp side, I put it in the model, to be able to easily reuse the form. For others, I have mostly been putting in the controllers, partly because of how large one of my models is.

I see a lot of first party forms in models and a lot in controllers, as well. Also, technically everything in an app is related to the app's content item in some way or another, so it's not as simple as "just put everything related to the item in its model".

[bfarber]

https://en.wikipedia.org/wiki/Model–view–controller

I'm not sure what you are asking here. There's no right or wrong answer that we can give you.

[evandixon]

From my limited experience using MVC, generally the controller is the thing responsible for interacting data over HTTP, and the model is only concerned with things related to the model and with exposing methods so that the controller can do what it needs with the model. This also helps from an automated testing perspective, because indirect inputs such as form data is a pain to set up.

That said, I definitely see the appeal of parsing form values in only one place when there are two controllers that would be doing it. Because first party applications do parse form values in the model (in a method called "processForm" IIRC), it doing the same wouldn't be out of place. Also this helps prevent code duplication.

Because neither way is wrong per se, it's up to you. I'm personally leaning towards having it in the model, since I would prefer avoiding code duplication over optimizing pure separation of logic. (Even though it feels wrong to intentionally disregard OOP best practices.)

[Midnight Modding]

@evandixonyes, that was really what I was getting at. In the first party apps, it's not consistently done one way or another. Some forms are in models and some are in controllers. Some updating of active records (or managing, in general) is done in models and some is done in controllers. It's not that I was misunderstanding the overall concept of controllers and models, it's that the first party apps aren't strictly adhering to it, so that is what got me wondering if I was misunderstanding the concept. There's a lot of processing of data in the controllers.

In a way forms could be thought of as belonging in either place, anyway. They're kind of a combination of interaction and processing, since the parsers and the if $form->values parts are processing and the rest is interactions with the user.

Or another way to look at forms is the processing is actually done in the form helper class, obviously, whereas the code actually "interacting" with the user is wherever you called the form helper class. So a lot of it is in how one looks at it.

Anyway, the most common pet peeve of people is duplication of code, so I try to concentrate on avoiding it. But there are a lot of imperfect situations, of course, where I guess you just have to pick one way and be done.

edit: and when I say some ARs are updated in controllers, obviously they're updated VIA the models. I just meant they call them in the controllers and sometimes they call them in the models. I'd assume the actual calling of them should be in controllers, but occasionally it is more convenient in the models (to create an object of a different class).

I feel like I'm doing it in an ok way, giving thought where I can. Can always tinker another time. I just like getting a lot of views on even simple decisions because almost always someone mentions something that some developers haven't thought of.

[Midnight Modding]

Speaking of refactoring and improving things, I am alllllmost done with a feature, using 700 lines of code, which in 3.x I used 3,482 for. And to top that off, I have a couple other 3.x methods where I think I can get to work in these same functions, so it's going to be a ton less clutter.