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

71–80 of 165 posts

Re: MVC Isn’t MVC

#71

Post by adasdasdas »

adamrezich wrote: post #65
adasdasdas wrote: post #63

Earlier quoted context omitted.

If you are building a framework to do that, you are probably just reinventing React

how so? I was under the impression React is a frontend framework, and I'm exclusively talking about the backend here. (plus, my thing is compiled to a single executable and not using JavaScript.)

React is just a way to procedurally generate templated HTML in the frontend. You can do the same thing in the backend but it just makes rerenders more expensive which could matter depending on how input heavy your application is. For example, if you update a row in the table, do you have to reload the entire page or just the row?

Re: MVC Isn’t MVC

#72

Post by ozim »

flatline wrote: post #66
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…

There is a 5000 line controller in one code base I worked on that speaks directly to this. I argued for something more modular/structured like MVVM because every bit of code where these questions arose would just end up in the controller in a grab bag of helper functions, which is exactly what happened.

I don’t think MVVM solves 5k line in a controller issue. You can write monster code using any style, language or pattern.

Re: MVC Isn’t MVC

#73

Post by smaudet »

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

I'll throw a wrench in - I like heavy views.

In HTML, in desktop GUIs/mobile Apps, in Databases, maybe games.

HTML is founded on the principle that your data is semantic, it knows how to submit and modify itself. You have tags. Every thing you can do in your view, is another thing you don't have to submit to some slow service or wait for a controller to do.

GUI frameworks are often like this as well, complex well-written UI components tend to remove a lot of supporting code from Controllers that just was there to half-support the UI having a slightly different formatting. The more you can push into your view, the more you can delete controller code, the more model code becomes a glorified "save" button. If your data is well-formed, and/or semantic, this model code can be very simple.

Games can be a lot like this as well - after you've loaded your geometry, pushing everything off to the GPU means your "game" code can be focused on simple things. Advanced things like physics and collision can be handled by actor-event logic. Controllers are still there to do some puppeteer-ing and models exist so save and networking code works.

Even databases can be view-heavy. A lot of database work amounts to building views of the same set of tables. Some analysis is done on the views, maybe, but keeping everything in normalized tables means losing out on view caching. Possibly this is more how vector databases work, as part of the data is where the data is not just what type the data is or which table it happens to be in.

Of course, none of this works great for heavy-networking cases (lots of net-code, lots of multiplayer events, lots of cross-database replication), but those are maybe less interesting to me - I prefer decentralized distributed models anyways. I generally value having more functionality at the local compute node, versus some monolithic service that may fail in a couple years time on the other side of the planet.

But that's just me.

Re: MVC Isn’t MVC

#75

Post by ozim »

roncesvalles wrote: post #37

MVC is one of those things (like Agile) that doesn't actually mean anything and people just nod their heads and gloss over it when someone mentions it. You know when something is that kind of thing when most discussion on it is about the definition.

It does mean something specific and useful. (both mvc and agile)

Only that people who are productive take it and try to use it and stop caring about nonsense details.

Where bunch of other people try to dissect it to find “true way” which is bunch of time wasting and annoying for people who need to get job done.

Then these people also blame flawed use of “pattern/process” for whatever went wrong because only if they could do it perfectly as described in some blog post everything would be perfect.

Meanwhile while they were arguing if daily standup should be 10 or 12 people and maybe 23 minutes instead of 19, and if controller is really a controller and should have less or more logic - productive people shipped two versions of app to test server and presented it to the customer already.

Re: MVC Isn’t MVC

#76

Post by 59nadir »

fellowniusmonk wrote: post #18

Is it weird that the inconsistent citation scheme really jumped out at me? > In December of 1979 _Tyrgve Reenskaug_, an employee of _Xerox PARC_ Later >In 2004, a Danish man

I found it really funny, it actually made me laugh out loud. It seemed very deliberate to me, though, so that's why.

Edit:

To clarify, I think DHH would probably laugh at this as well, which is why I feel it's not so much laughing at anyone as it is laughing with them.

Re: MVC Isn’t MVC

#78

Post by adamrezich »

gls2ro wrote: post #68
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…

one my wonder about what could this be: > routes" (procedures, mapped to URL patterns, that execute logic such as accessing models (cached or queried) A "route" that executes logic such as accessing models responding with an output based on what mime type was requested, can set a layout or template for the view ... changing the name to "route" does not change the pattern that you are implementing here. Rails Controll…

it's been a very long time since I did anything with Rails… but I recall there being Ruby code in the "Views", which is something I'm choosing to avoid entirely. all logic is executed in the "Route" (or whatever it's called in the end) procedure, which is where, if you want to output HTML, you invoke a "Render" macro that takes in the template name and optionally any variables you want to pass in. the HTML templates have a simple, Mustache-like syntax (insert parameter, insert nested template/"partial"), but it's just plain HTML with some {{placeholdery-looking stuff}}. maybe I'll add a JSON "renderer" if I need it, and I still need to get static file loading to work, but other than that, this framework does pretty much everything I want to do as far as website backends go, and it compiles to a single executable. it's not going to be The Future Of Web Development, but it will be nice (for me at least) to make small-to-medium-sized websites with, in large part because it's much easier for me to reason about "Models (structs), Routes (code), Templates (HTML)" than "MVC", or at least, how I remember "MVC" feeling in Rails, and Django.

Re: MVC Isn’t MVC

#79

Post by adamrezich »

adasdasdas wrote: post #71
adamrezich wrote: post #65

Earlier quoted context omitted.

how so? I was under the impression React is a frontend framework, and I'm exclusively talking about the backend here. (plus, my thing is compiled to a single executable and not using JavaScript.)

React is just a way to procedurally generate templated HTML in the frontend. You can do the same thing in the backend but it just makes rerenders more expensive which could matter depending on how input heavy your application is. For example, if you update a row in the table, do you have to reload the entire page or just the row?

my bad, I wrote "web application" above—I meant to say "website", like, year-2008-level-of-interactivity stuff. I'm neither interested in nor proposing a solution for anything on the frontend side of things at all, because I'd suspect you're correct, I would probably just reinvent React et al.

Re: MVC Isn’t MVC

#80

Post by pmichaud »

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

I use services, but they are not a random grab-bag of methods. What do you even have in mind when you say this?
Post reply on HN