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

81–90 of 165 posts

Re: MVC Isn’t MVC

#81

Post by siilikuin »

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…

Indeed. Th C in MVC must stand for carcinization, given how often completely independent parties reinvent this one.

Re: MVC Isn’t MVC

#82

Post by zerbinxx »

pmichaud wrote: post #80
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 use services, but they are not a random grab-bag of methods. What do you even have in mind when you say this?

I too use services and they are where the business logic lives. In the case of “create user” they’re basically no-op repository methods, in the case of “sync user profile data” they may invoke storage or external service calls in a certain business-logical order, but they map exactly to the applicable domain(s) - putting user-profile methods in the user service is when you end up with muddled service boundaries

Re: MVC Isn’t MVC

#84

Post by KronisLV »

vsareto wrote: post #27
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…

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 interesting to see how different languages and frameworks handle common concerns, for example, with some you will have repositories, with other the model objects themselves will handle queries through some ORM.

Re: MVC Isn’t MVC

#85

Post by nologic01 »

Somehow applications running on a single machine (classical desktop apps) cannot be the same class of patterns as a browser-webserver combo where two different machines may persist different pieces of data, respond to different types of events etc. The browser receives human user input and displays model information. For the web server the "user" is the browser.

Effectively you might want to start with an abstract stacked MVC-MVC pattern and see if anything is actually redundant.

I dont think clearing those things up is an academic pursuit. The confusion about those patterns is an important data point about the quality and accuracy of our communication about architectural designs.

If you thing of the MVC discussion as a sort of metacode, its full of metabugs.

Re: MVC Isn’t MVC

#86

Post by Marazan »

ozim wrote: post #72
flatline wrote: post #66

Earlier quoted context omitted.

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.

Nothing can stop bad code but MVVM helps as it is a better mental scaffold than the "everyobne 'knows' what it is but no one can agree what it is" MVC

Re: MVC Isn’t MVC

#87

Post by midasz »

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…

MVC is a frontend paradigm

When you're talking about a table of Users you are talking about an entity of User. This can contain extra stuff that's not relevant to the frontend - like the password or lastUpdatedDate, you name it.

In your example, when you talk about a Model, you talk about a user Entity representation. There's a transformation there. The frontend posts a Model (or a DTO) to the backend API, the backend does the transformations it needs (e.g. retrieving the user Entity based on the model user id, mapping updated field values from the model to the Entity, and saving the Entity to the database).

The view is the representation template, the model is what's needed to fill in the template, and the controller does CRUD operations to a backend API.

Edit: or is this MVVM? These days I mainly do backend stuff but I used to call this MVC

Re: MVC Isn’t MVC

#88

Post by bsaul »

strken wrote: post #28
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…

> My take on the model layer is : write everything that’s not strictly specific to your UI there. My take is this, except with the caveat that the larger a model gets, the closer to declarative it should become. You touched on this by saying the model layer rather than just the model, but it's worth emphasising. You can achieve this by abstracting out the messy bits, e.g. moving some hooks to a task queue (processing…

Yes, there's definitely a confusion in the meaning of the word "Model":

All objects belonging to the model layer don't have to match a data type. For an online shopping app, you may have an "Item" object, but your purchase logic may be in a "Purchase" service object, which needs a "PurchaseRestAPI" to perform HTTP calls, etc.. They all belong to the "Model" layer.

Correctly structuring your model layer is the key for a maintainable application. The problem with most mobile developers is that Apple has been demoing a lot of features on the view layer (because of the cool UI effects the user sees), but it's something that has to come in the end. First you need to model your domain logic properly. Then you can see how to represent it on a given user interface.

Re: MVC Isn’t MVC

#89

Post by throw310822 »

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 receive from the model the pre-digested data it provides and translate it into html. Similarly, the controller only needs to translate user input in terms of high-level operations on the model, without ever having to interface with a database.

Re: MVC Isn’t MVC

#90

Post by myaccountonhn »

preommr wrote: post #45
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).

Software is just a giant ORM.
Post reply on HN