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

151–160 of 165 posts

Re: MVC Isn’t MVC

#151

Post by ebiester »

regularfry wrote: post #105
ebiester wrote: post #42

Earlier quoted context omitted.

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.

This is a specific problem with the Active Record pattern, rather than something intrinsic to MVC, and it's exactly why AR is fine for simple apps where the business logic looks a lot like manipulating a row in a database, but breaks down for anything more involved. But also there's no reason you can't have non-database-backed classes sat next to AR models, if they make sense in the domain. Not everything needs to be…

What, then, is a service other than a model without a database table?

Re: MVC Isn’t MVC

#152

Post by derefr »

jrochkind1 wrote: post #60
derefr wrote: post #31

So, the original MVC was designed in the context of green-screen terminal systems. In that context, this “design pattern” really isn’t a design pattern per se; it’s just a formalism over the code you’d inevitably write to make such a system work. In a green-screen system: • the “view” is the terminal buffer state — not even a “virtual DOM” version of it, but literally the buffer state itself (under 3270 protocol, pro…

> really isn’t a design pattern per se; it’s just a formalism over the code you’d inevitably write to make such a system work. I feel like that's what all the original design patterns were, though, pretty much! Although maybe not "inevitable", people could write all sorts of spaghetti messes, but the original design patterns were basically formalisms of the sane ways to handle a given problem in a concise elegant way…

"Inevitable" was the crucial distinction I was trying to make. Something isn't a design pattern if, no matter how you write it, the shape of the problem domain means that the solution looks a certain way. What you have in that case is just a formalism for describing the reflected problem domain.

A design pattern is a highlighted, reified tactical choice in implementation. It's something that you, as a programmer, want to give a name to, so that you then have words to communicate the choice you made at design time, to talk about where that choice is valid/proper/important to make.

These patterns can then be shared with people who haven't worked on problems where that choice is relevant before, where knowledge of the pattern then acts as a form of crystallized professional experience. Rather than looking at your individual problem, and then evaluating the pros and cons of certain designs on a case-by-case basis, you can recognize that the problem fits one or more patterns you've learned, and then merely evaluate (or rely on prior evaluations documented by others) the pros and cons of applying the pattern.

When there's only one inevitable way to do things, a formalism is just there to allow software-engineering academics to model what you're doing; but you yourself, when coding, don't need those words to talk (or think!) about what you're doing.

---

An analogy:

A design pattern is like a martial-arts movement form. Rather than having to solve for the optimal movement to block/parry/return an attack on a case-by-case basis, learning the forms of a given art gets you to think in terms of which well-known, high-level movements would be best to apply in a given situation — which massively decreases cognitive overhead, allowing you to actually fight someone in real-time.

But there's no martial-arts movement form you need to know or learn for "taking a drink of water." If there's a glass of water on a table in front of you, then there's only one natural way to pick the glass up and hold it to your mouth such that you can drink from it. "Taking a drink of water" is not a movement form, because there's no cognitive load placed on you for determining how you're going to do it. If you formalize "taking a drink of water" as a movement, that would only be for academic purposes, not practical ones.

Re: MVC Isn’t MVC

#153

Post by nightpool »

smaudet wrote: post #73
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

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-wri…

that's fine! I'm happy with heavier views. The thing i'm arguing against is the Rails pattern of having FooBarService classes that are effectively just a single method and cobbled together in completely random ways instead of using actual model methods.

Re: MVC Isn’t MVC

#154

Post by adamrezich »

pravus wrote: post #95
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 yoursel…

cool, thanks for the insight. are there any materials you'd recommend for reading up on this kind of stuff? I have a fair bit of insight from having done things in various frameworks over the years, but if there's any resources you have in mind, I'd be more than happy to take a look.

Re: MVC Isn’t MVC

#155

Post by kaba0 »

It’s a topic I’m very interested in! A very eye-opening comment I have seen on HN was this: https://news.ycombinator.com/item?id=4190252

> It helps me to remember that in Smalltalk the idea was to always have pairs. They were always the same object split in two; each view had its own controller and vice versa. The controller is supposed to be input-oriented and the view is supposed to be output-oriented

Another commenter here put it nicely: your “whole application” is the model. The view-controller pair over could be one for a terminal, or a website, or a desktop app, the model should be reusable. A controller isn’t, handling a click on something doesn’t make sense in a terminal.

Re: MVC Isn’t MVC

#156

Post by regularfry »

ebiester wrote: post #151
regularfry wrote: post #105

Earlier quoted context omitted.

This is a specific problem with the Active Record pattern, rather than something intrinsic to MVC, and it's exactly why AR is fine for simple apps where the business logic looks a lot like manipulating a row in a database, but breaks down for anything more involved. But also there's no reason you can't have non-database-backed classes sat next to AR models, if they make sense in the domain. Not everything needs to be…

What, then, is a service other than a model without a database table?

Eh? It's a service. It represents a domain operation (or group of operations) that hasn't been coalesced into either a value type or a transient entity, both of which are also models without database tables, both of which are preferable to a service if they fit the domain.

None of this says that putting business logic into a separate class to the thing that happens to back onto a database row is correct because of single responsibility. That's a fundamental misunderstanding of the SRP.

Re: MVC Isn’t MVC

#157

Post by ptx »

samsquire wrote: post #143
danabrams wrote: post #135

Earlier quoted context omitted.

Yes absolutely. Reenskaug has stated that MVC was designed for simple operations (and co-designed DCI as an architecture for more complicated ones). And a number of the early OOP people including Alan Kay, have said something to the effect of “Erlang is the only true OOP language.” I did a deep dive reading the early papers and watching the lectures from the 70s, 80s and 90s on this a few months ago. The early Xerox…

This idea of "multiple objects" operating as "one object together" is some idea I really like too. a) A good object orientated API is enjoyable to use, if it maps well to what you want it to do. Look at the developer productivity of ActiveRecord, Django ORM, SqlAlchemy or Hibernate. The object graph model is kind of fun to work with and many developers prefer it to working directly in SQL. b) Where object orientated…

> Most cross platform GUI frameworks are object orientated even if the underlying graphical APIs are procedural. For example, win 32 API is procedural.

Well, win32 is kind of object-oriented, in a way, even though it doesn't always map cleanly to OOP languages.

Windows are basically objects whose methods you call through SendMessage. There is even inheritance by replacing the window procedure and delegating to the parent procedure. There is polymorphism in that many kinds of windows support the same messages (e.g. WM_PAINT) and can decide how to handle them.

Re: MVC Isn’t MVC

#158

Post by ptx »

unconed wrote: post #131

Just going to leave this here: "There is a View, which only knows how to tell you something. There is a Controller, which only knows how to manipulate something. This is a crack team of a quadriplegic and a blind man, each in separate rooms, and you have to delegate your UI to them? How, in the name of all that is holy, are you supposed to do that? Prisoner dilemmas and trolleys? No really, if the View is a TextField…

> This implies either one of two things. First, that the Controller has to be specialized for the target widget. It's a TextController, with its own house key to the TextView

Yes, this appears to be the way it worked in Smalltalk-80 [1]. You had StringHolderView and StringHolderController which used a StringHolder as the model.

> Or second, that the Controller doesn't do anything useful at all

The controller in Smalltalk-80 controlled input focus. The view wouldn't be able to receive any input without a controller:

"Class Controller does include default scheduling behavior. It takes the point of view that only one controller is to be active at a time; that is, only one controller at a time mediates user input actions. Other views could be displaying information in parallel, but the user's actions are to be interpreted by a single controller. Thus, there is behavior in class Controller for determining whether a controller needs to receive or maintain control."

[1] https://web.archive.org/web/20100921030808/http://www.itu.dk...

Re: MVC Isn’t MVC

#159

Post by andrekandre »

danabrams wrote: post #130
layer8 wrote: post #128

Earlier quoted context omitted.

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

for some reason i couldn't open the link... maybe t got truncated?

Re: MVC Isn’t MVC

#160

Post by danabrams »

andrekandre wrote: post #159
danabrams wrote: post #130

Earlier quoted context omitted.

Source: https://citeseerx.ist.psu.edu/document?repid=rep1&type=pdf&d... The source is Trygve Reenskaug, the originator of the idea.

for some reason i couldn't open the link... maybe t got truncated?

It's a pdf. It opens for me when clicking. Are you on a browser that can't easily open PDF?
Post reply on HN