Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

MVC Isn’t MVC

collindonnell.com

Post reply on HN
Print view View original

121–130 of 165 posts

Re: MVC Isn’t MVC

#121

Post by bsaul »

mpweiher wrote: post #97
bsaul wrote: post #9

Not sure why author got the impression apple’s models had to be « dumb data containers ». Actually, having dumb models is the surest way to completely screw up your controllers design, since you’re now left with no other places to write your business logic in. This leads to either weird trees of controller inheriting each other for the sake of reusing some data processing piece, or singletons everywhere which makes t…

> apple’s models had to be « dumb data containers ». They don't "have" to be, but that's very much the result of what Apple has been advocating, what the community tells itself and what happens. > Actually, having dumb models is the surest way to completely screw up your controllers design, since you’re now left with no other places to write your business logic in. Exactly. And the coordination logic. Alas, that is e…

that's also my tip for devs working in my team when they ask me where they should write a piece of logic :

- would you need to change that code if the UI is now a command line application ? No ? then it's in the model layer.

EDIT: i've also been in those codebase a LOT, and actually decided to create a blueprint of a mobile codebase with an emphasis on the model layer. I'm not going to post it here because i want to remain anonymous, but i've been using it in my projects (and my friend's have been doing the same) for the past 6 years..

Re: MVC Isn’t MVC

#122

Post by danabrams »

The M in MVC has come to mean “data model,” but it originally referred to the “mental model” of the user. What kind of thing are we trying to manipulate and what is the user’s mental model of such a thing?

How about a bank account? A mental model of a bank account would include useful operations like deposit, withdraw, transfer, checkBalance, and these would be the methods on the object. The data schema and the persistence would be necessary, of course, but an implementation detail. Models were smart and mapped to human perceptions of a thing, rather than dumb data persistence layers.

These kind of business logic operations have often been moved into controllers, which couldn’t have been further from the original intention.

MVC, smalltalk, OOP we’re all about stopping and thinking about the way humans think while interacting with computers. It was about designing nice interfaces for interaction based on human expectations, not database requirements. Internal object schemas and data persistence were implementation details of an object that could—if you did it right—be easily changed without changing the interface.

But we can’t help ourselves, and instead OOP today is a world of getters and setters with a little bit of data validation (if we’re lucky) and models are just a schema plus a generic data persistence interface (maybe an orm). And the business logic exists in the controller, the least important, least reusable component of the architecture.

Re: MVC Isn’t MVC

#123

Post by cies »

nightpool wrote: post #40
vsareto wrote: post #27

Earlier quoted context omitted.

We really need to call it Model-View-Controller-Service-Repository and be done with it. That is actually what happens 99% of the time. Logic is done within services and where the complex dependency graphs live. Repositories do the data retrieval. The controller is a traffic cop. The model is a data transfer object with maybe some calculated fields. The view makes things pretty.

No, please for the love of god stop writing services. Having random grab-bags of methods makes it infinitely harder to find what code lives where, instead of putting it into models where we have 20+ years of OO design principles (single responsibility, open to extension, liskov substitution, interface segregation, etc) to guide us. "Fat models, skinny controllers" is a Rails guiding principle for a reason

You start with MVC, following "the fat-model, skinny controller" rule of thumb.

Now the Models become obese. So you split out the Repository logic.

Now you need a place to do "client onboarding" which creates a Customer, a User, a BillingInfo, a bunch of things to show the new client a non-empty environment... Where does this live? In the Customer model? Nah. In a repository? Certainly not.

No. That's when the OnboardingService comes along.

note: We use jOOQ so our "Model entities" are generated from the db schema and thus logic-less.

Re: MVC Isn’t MVC

#124

Post by cies »

KronisLV wrote: post #84
vsareto wrote: post #27

Earlier quoted context omitted.

We really need to call it Model-View-Controller-Service-Repository and be done with it. That is actually what happens 99% of the time. Logic is done within services and where the complex dependency graphs live. Repositories do the data retrieval. The controller is a traffic cop. The model is a data transfer object with maybe some calculated fields. The view makes things pretty.

> Model-View-Controller-Service-Repository Where would you put validation logic, though? I mean, some of it might need to just check whether a domain object has its fields filled out, but other validations might need to cross reference DB data to make sure that everything is valid in accordance to the business rules. Ergo, we might have Model-View-Controller-Service-Repository-Validator Even without being silly, it's…

Most MVC frameworks have some soft or form DTO notion, as a form does not map 1-on-1 to one db record. The form DTOs in our app also holds the logic to validate itself.

Basically, like sibling post mentioned: you put it where it makes sense.

Doing validation on db entities, is certainly not a place it makes sense (except in the most trivial cases, hence the common mistake).

Re: MVC Isn’t MVC

#125

Post by mpweiher »

bsaul wrote: post #121
mpweiher wrote: post #97

Earlier quoted context omitted.

> apple’s models had to be « dumb data containers ». They don't "have" to be, but that's very much the result of what Apple has been advocating, what the community tells itself and what happens. > Actually, having dumb models is the surest way to completely screw up your controllers design, since you’re now left with no other places to write your business logic in. Exactly. And the coordination logic. Alas, that is e…

that's also my tip for devs working in my team when they ask me where they should write a piece of logic : - would you need to change that code if the UI is now a command line application ? No ? then it's in the model layer. EDIT: i've also been in those codebase a LOT, and actually decided to create a blueprint of a mobile codebase with an emphasis on the model layer. I'm not going to post it here because i want to…

Cool. And great to see I'm not alone.

I've written about mine here:

https://blog.metaobject.com/2022/06/blackbird-simple-referen...

Maybe we should form APSMA, the Association for the Promotion of Sane Mobile Architecture?

Re: MVC Isn’t MVC

#126

Post by samsquire »

danabrams wrote: post #122

The M in MVC has come to mean “data model,” but it originally referred to the “mental model” of the user. What kind of thing are we trying to manipulate and what is the user’s mental model of such a thing? How about a bank account? A mental model of a bank account would include useful operations like deposit, withdraw, transfer, checkBalance, and these would be the methods on the object. The data schema and the persi…

Thanks for this insightful comment.

I think of the model as being the perfect API for your system that you would happily use if you were in a REPL or in a command line.

It's primary goal should be elegance to do the things that a user would want to do with your system, from a programmatic perspective.

The programmatic interface is a user interface that's not necessarily graphical.

Very few people treat OOP as interacting objects with message passing as in Smalltalk and I think we've lost something.

Re: MVC Isn’t MVC

#127

Post by danabrams »

samsquire wrote: post #126
danabrams wrote: post #122

The M in MVC has come to mean “data model,” but it originally referred to the “mental model” of the user. What kind of thing are we trying to manipulate and what is the user’s mental model of such a thing? How about a bank account? A mental model of a bank account would include useful operations like deposit, withdraw, transfer, checkBalance, and these would be the methods on the object. The data schema and the persi…

Thanks for this insightful comment. I think of the model as being the perfect API for your system that you would happily use if you were in a REPL or in a command line. It's primary goal should be elegance to do the things that a user would want to do with your system, from a programmatic perspective. The programmatic interface is a user interface that's not necessarily graphical. Very few people treat OOP as interac…

I agree, and I wonder if this is just what happened as an accident of history or so much a tendency of human nature that we couldn’t have done it any other way. Maybe simple data models is the mental model of computing that couldn’t be easily changed.

Re: MVC Isn’t MVC

#128

Post by layer8 »

danabrams wrote: post #122

The M in MVC has come to mean “data model,” but it originally referred to the “mental model” of the user. What kind of thing are we trying to manipulate and what is the user’s mental model of such a thing? How about a bank account? A mental model of a bank account would include useful operations like deposit, withdraw, transfer, checkBalance, and these would be the methods on the object. The data schema and the persi…

> it originally referred to the “mental model” of the user.

Do you have a source for that? I agree that that’s a useful way to think about MVC (somewhere downthread someone wrote that the model should be like a headless version of the application, which is similar), but I’m curious about the original expressions of that idea.

Re: MVC Isn’t MVC

#129

Post by skeeter2020 »

danabrams wrote: post #122

The M in MVC has come to mean “data model,” but it originally referred to the “mental model” of the user. What kind of thing are we trying to manipulate and what is the user’s mental model of such a thing? How about a bank account? A mental model of a bank account would include useful operations like deposit, withdraw, transfer, checkBalance, and these would be the methods on the object. The data schema and the persi…

>> These kind of business logic operations have often been moved into controllers, which couldn’t have been further from the original intention.

Moving them out of the object model without putting them in the controller is actually a good thing IMO. I don't want to test controller plumbing or data persistence, but I do want to focus on the business logic, so simple controllers that route to smart objects with dumb data models helps. I agree the smart parts don't belong in the controller but I don't think it's as bad as you make it sound.

Re: MVC Isn’t MVC

#130

Post by danabrams »

layer8 wrote: post #128
danabrams wrote: post #122

The M in MVC has come to mean “data model,” but it originally referred to the “mental model” of the user. What kind of thing are we trying to manipulate and what is the user’s mental model of such a thing? How about a bank account? A mental model of a bank account would include useful operations like deposit, withdraw, transfer, checkBalance, and these would be the methods on the object. The data schema and the persi…

> it originally referred to the “mental model” of the user. Do you have a source for that? I agree that that’s a useful way to think about MVC (somewhere downthread someone wrote that the model should be like a headless version of the application, which is similar), but I’m curious about the original expressions of that idea.

Source: https://citeseerx.ist.psu.edu/document?repid=rep1&type=pdf&d...

The source is Trygve Reenskaug, the originator of the idea.

Post reply on HN