Post #2074139

2026-05-06 10:17 UTC

Starting with seperation of concerns, the view should be code that handles presentation of elements of a page, perhaps moving HTML around either based on user information or info from deeper in the stack. I imagine view code could be largely client side without too many issues (unless templating is involved, in which case i've been made aware templating can introduce potential vulnerabilities). The model should be responsible for operating on information the user inputs from the view or incoming data from the database. It may not interface with the database directly, and it probably shouldn't, given that if the model is client-side, I imagine tampering could leave the database vulnerable. I'm not sure if it makes sense for the model to be server-side at all. The controller is a (probably) server-side application that interfaces between the front end and the database. It sanitizes input before db operations are done and packages db information into json or something that can be sent to the frontend for processing, most likely the model since that's what the model does.

Replies (1)

@crocodisle@woof.tech 2026-05-06 10:45

Is my conception a different pattern, or is MVC just that inconsistent in how it's conceptualized? If the controller is client-side, it's vulnerable to tampering, so it shouldn't make db queries, probably. Am I wrong about this? If the controller acts as a middleman between the view and model, then, by the pattern, I assume the model runs server side (since once again, vulnerable db code otherwise), but then all operations are running on the server, costing server resources that aren't related to requests for db information, which costs more money for the company paying for hosting. Why would non-sensitive business logic need to be executed server side if it can be executed client side? It's a waste of money if it isn't client side! If a controller is supposed to be an interface between the view and model, it seems rather unnecessary unless there is a specific business concern requiring the view model communication to be incredibly decoupled, a la the facade pattern. I could understand how in larger companies this might help with development, but it doesn't seem any better or worse than referencing one from the other, or having the view hold an instance of the model to operate on from a separation of concerns pov. The more I think about it from a decoupling pov, it seems nice, but perhaps hardly necessary for basic CRUD apps.

Open ##2075576