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

41–50 of 165 posts

Re: MVC Isn’t MVC

#41

Post by smackeyacky »

keyle wrote: post #19

There is a lot of truth in what the Author wrote, however he completely missed the MVVM pattern and confused it with MVC. The MVVM pattern, originally designed by MSFT for Silverlight, showed a way that basically cleaned up a lot of the issues with MVC. That is what SwiftUI uses today, MVVM, as you can compare with his diagram of what he calls "Apple's MVC" and this diagram from MSFT: [1]. In fact, I'd go out on a li…

Funnily enough, the 1990s VisualWorks UI moved on from the original MVC implementation into a pile of complexity involving adaptor classes and automated event processing, so even the Smalltalk guys knew the original implementation wasn't enough for most GUI problems.

Re: MVC Isn’t MVC

#42

Post by ebiester »

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

Until the moment that models have to call other models to get anything done.

The problem is that the models often get too tied with the database implementation. Then, you're separating business logic that doesn't make sense to separate.

The fat model ruins single responsibility because the database table is not a good proxy for one reason to change.

Re: MVC Isn’t MVC

#43

Post by sparkie »

keyle wrote: post #19

There is a lot of truth in what the Author wrote, however he completely missed the MVVM pattern and confused it with MVC. The MVVM pattern, originally designed by MSFT for Silverlight, showed a way that basically cleaned up a lot of the issues with MVC. That is what SwiftUI uses today, MVVM, as you can compare with his diagram of what he calls "Apple's MVC" and this diagram from MSFT: [1]. In fact, I'd go out on a li…

I like the Model-View-Adapter[1] architecture, which is basically what you get by reversing the arrows between the View and ViewModel in MVVM. The view and model are oblivious to each other and to the adaptor directly (but interact with it indirectly), and the adaptor depends on both the view and model.

My use case for this a bit different than regular UIs though. I've used it in an MMO server, with the view representing the network protocol which clients interact with, and the model being the state of the game world. The adapter receives messages from game clients asynchronously and updates the world, then sends messages back to the clients affected by the change in the world state.

IMO it makes sense to have the inverted dependency in this case. If the view depended on the adaptor, then changes to the game server behavior would impact the network protocol, which would also force changes to user clients each time the server gets updated. Ideally we want to be able to make regular updates to the server without impacting clients.

[1]:https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93ada...

Re: MVC Isn’t MVC

#44

Post by ysavir »

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…

There's two definitions these days for the term "model" in MVC:

1. An object that models part of the service/product. Meaning, not something related to the operation of the medium by which the service/product is delivered, but any operation that models the service/product itself, independent from medium. This could be a representation of a DB row, a service object, a decorator, or any other piece of logic that relates to what you do.

2. An object that reflects a DB row, but not anything that represents other parts of the service/product. I don't know the full history, but probably connected to the rise of ORMs and Rails, and when devs got in the habit of throwing almost all product logic either into controllers or Active Record models. And when you want to start putting the bulk of that code in dedicated, non-DB files, you have so many active record files that you don't want to muddy up the `models` directory with non-DB code too, so you create other directories alongside `models`, `views`, and `controllers` to house the other files.

The author may have been using definition 2, where models are strictly seen as DB-related code, and having them be "dumb data containers" is useful as it enforces extracting operational logic to classes better suited for that logic. But since they get put in other directories, they aren't seen as "models", despite technically still belonging to the "model" part of MVC.

Re: MVC Isn’t MVC

#45

Post by preommr »

misterbwong wrote: post #2

If you squint a bit, the "original" MVC looks eerily similar to the one-way data flow pattern popularized by flux/redux. https://en.wikipedia.org/wiki/React_(software)#Unidirectiona... edit: better link

If you squint almost of all software looks like MVC because it's essentially just, input(data)/processing(controller)/output(view).

Re: MVC Isn’t MVC

#46

Post by LeonB »

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. Wait, who is “you”? The model?

The model tells the view about itself. This is early O O. Everything is an object. And objects have power and self awareness. When the view receives the message telling it about the model, it does what it has to do to make the model viewable.

So the model and the controller don’t know about html. The view received a message (the current state of the model, or a delta thereof) and responds accordingly.

Re: MVC Isn’t MVC

#47

Post by LeonB »

ebiester wrote: post #42
nightpool wrote: post #40

Earlier quoted context omitted.

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

Until the moment that models have to call other models to get anything done. The problem is that the models often get too tied with the database implementation. Then, you're separating business logic that doesn't make sense to separate. The fat model ruins single responsibility because the database table is not a good proxy for one reason to change.

> models have to call other models.

“You're very clever, young man, very clever," said the old lady. "But it's turtles all the way down!"

Re: MVC Isn’t MVC

#49

Post by joeyguerra »

Fun article.

Just a note, MVC requires the Observer Pattern. If the Observer Pattern isn't present, it's not MVC. And it's fine if it's not MVC. It can be called something else. It's fine.

RoR doesn't implement the Observer Pattern; thus, not MVC. It can just be RoR. AspNet MVC doesn't implement the Observer Partner; not MVC. It can just be AspNet.

Here's another reference to Tyrgver's explanation of the MVC language. Although, it's lack of code (and details) is probably one reason why people misunderstand MVC ;)

https://folk.universitetetioslo.no/trygver/themes/mvc/mvc-in...

Woohooo! Fun times.

Re: MVC Isn’t MVC

#50

Post by [deleted] »

ebiester wrote: post #42
nightpool wrote: post #40

Earlier quoted context omitted.

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

Until the moment that models have to call other models to get anything done. The problem is that the models often get too tied with the database implementation. Then, you're separating business logic that doesn't make sense to separate. The fat model ruins single responsibility because the database table is not a good proxy for one reason to change.

[deleted]
Post reply on HN