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

91–100 of 165 posts

Re: MVC Isn’t MVC

#91

Post by starbugs »

LudwigNagasena wrote: post #32

> Model updates View, View sees User, User uses Controller, Controller manipulates Model. > This makes a lot of sense to me, and I think I understand it pretty well. It looks simple at first glance, but it actually makes zero sense under closer inspection. Let’s take a simple example. A table of users. You take a table from the database and put it into an html tag table. Wait, who is “you”? The model? Do you want you…

In Apple MVC, the view controller is IMHO actually primarily a way of avoiding the need to subclass views. After about 25 years with one or the other form of MVC, I am convinced that most of it is just born out of a weird OOP mental model.

Re: MVC Isn’t MVC

#92

Post by fifticon »

t3rra wrote: post #23

What MVC refers these days is not of MVC from 1979 but from the Design Patterns by Gags of Four and they did not mean the patterns should be applied strictly as is. So.. what? What is the point of the article? He does not seem to really understand the purpose of design patterns and it in practice

I would upvote for 'gags of four'.

Re: MVC Isn’t MVC

#93

Post by hardware2win »

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…

>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.

There is such a place: model

Re: MVC Isn’t MVC

#94

Post by pravus »

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…

Validation logic needs to be spread throughout the system because your validations are all context sensitive to the operations being performed. It's not always possible to front-load that into a simple schema in your transports and each component needs to be correct in its own domain.

Re: MVC Isn’t MVC

#95

Post by pravus »

adamrezich wrote: post #56

for simple web application backends, why does one need more than just "models" (structs, that describe database tables/rows, using something like "an ORM" but more lightweight, so as to provide query building, caching, etc.) and "routes" (procedures, mapped to URL patterns, that execute logic such as accessing models (cached or queried) and then responding with output from a simple HTML template system, or possibly a…

You don't need more than what you have. You have essentially built a minimal MVC. Everything else you add is just stuff that other people added to other MVC projects to make life easier for them in some way. Web MVCs are basically just opinions on the way to handle HTTP requests and are meant to speed up the dev process if you agree with all of its boilerplating/tooling.

My only recommendation is to just keep yourself aware of url/form encodings, path handling, and common pitfalls related to handling HTTP requests in general.

Re: MVC Isn’t MVC

#96

Post by bonzini »

throw310822 wrote: post #89
LudwigNagasena wrote: post #32

> Model updates View, View sees User, User uses Controller, Controller manipulates Model. > This makes a lot of sense to me, and I think I understand it pretty well. It looks simple at first glance, but it actually makes zero sense under closer inspection. Let’s take a simple example. A table of users. You take a table from the database and put it into an html tag table. Wait, who is “you”? The model? Do you want you…

> You take a table from the database and put it into an html tag table. > Do you want your view to know how to connect to a db? I think this is where there's a misunderstanding: you think of your model as "a database". A database is not a model, a database is just a storage layer. A model is an object that provides an api with high-level business operations and views on data. At that point, your view needs only to re…

In fact the original MVC was done with Smalltalk which has a persistent image. So the Smalltalk system itself _is_ the storage layer in which model objects live.

Re: MVC Isn’t MVC

#97

Post by mpweiher »

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 exactly what happens, and I've been in enough of these codebases.

It's actually a bit more complex than that, as what people seem to aspire to is write self-contained widgets for their functionality, essentially slicing the application vertically most of the time. And that appears to have a bunch of causes, for example the PM->Design->Engineering process chain that also appears to be standard (and broken).

> My take on the model layer is : write everything that’s not strictly specific to your UI there.

YES.

UNDERLINE.

BOLD.

BLINK.

Repeat 100 times. Say it loud. Sing it. Shout it.

The "Model" is an object that is the headless application. It implements and coordinates all the functionality. You put a thin GUI on top of that. Or a different GUI. Or an API. Or a WebUI. Or a CLI....

Re: MVC Isn’t MVC

#99

Post by mpweiher »

> Model updates View, View sees User, User uses Controller, Controller manipulates Model.

Yeah, not really. The View is actually also used to manipulate the model, most of the time.

The Controllers are there for more complex situations, and stuff that isn't really relevant any longer, like handing the physical input devices. We've abstracted most of this away now and it is packaged in the toolkits in such a way that you don't have to translate between the mouse controller and the UI/Model.

It is also important to note that these are roles not objects, meaning a single object can have multiple of these roles. As an example, Apple's views have had a lot of controller functionality in them since forever. Which is why the appearance of "ViewControllers" really confused me.

At best I can tell there were two reasons for them: first, to implement all the "remaining" functionality that couldn't be handled by the hooking up widgets to CoreData-generated entities using bindings in Interface Builder. Alas, that turned out to be quite a bit. Second, as a memory optimisation in early iOS, as placeholders for Views that could be discarded and recreated on-demand.

Neither of these is relevant today.

See also:

https://blog.metaobject.com/2015/04/model-widget-controller-...

https://blog.metaobject.com/2015/04/reactnative-isn.html

https://blog.metaobject.com/2017/03/concept-shadowing-and-ca...

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

Re: MVC Isn’t MVC

#100

Post by resonious »

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…

Personally I kind of like dumb models. Dumb models means I don't have to think too hard about "a.affect(b)" vs "b.be_affected_by(a)". I can just write functions that do what I want right now. "do_my_thing(a, b)". No reason to be doing anything else when programming. If you have people making controllers inherit each other just to share functionality then they're probably brainwashed by OOP. Stuff like inheritance and mixins only exist to solve fake problems that make no sense outside of C# or Java. To me, singletons and plain-ole-functions are pretty easy to deal with in most languages - I just ask the editor where a function gets used or where it's defined. If your language doesn't support that kind of thing (looking at you, Ruby) then again that's another problem caused by tooling.
Post reply on HN