What is wrong with writing web applications in a way that merges repository layer with view and with controller in the same file?

Question

is there anything wrong with writing code in a way that merges view, repository, controller in the same file?

i.e.

global $db;
// or $db = DBSingleton::get_db_instance();
// or global $container; $db = $container->get(Db::class);
$id = filter_var($_POST['id'], FILTER_VALIDATE_INT);
$record = $db->parameterized_query("SELECT data from table where id = ?", [$id])->getResult();
foreach($record as $row)
    echo $row['data'] . PHP_EOL;

etc. basically everything is in the same file and there is very little, if any use of dependency injection, and any view code, any database access code, and any "reading variables from HTTP Request object", are in the same file.

Why are modern frameworks advocating against this style? What are the things that can go wrong if I choose to use this way of coding in my work?

Answer 1

There's nothing wrong with it. You just lose Separation of Concerns, that's all.

You can write single-page applications in precisely this way using Vue. Code folding in Visual Studio Code insures that the thing stays readable.

But the practical limit of such pages is about 20,000 lines of code (including the HTML). That is a lot of code in a single file, and it limits you to pretty small applications before you run out of architectural air. Then you wind up splitting your code into separate files anyway.

For anything but the smallest of applications, stick to an architecture that allows your application to expand naturally as your needs grow.

Answer 2

Merging all code into one file, and not utilizing functions (as your code example suggests) also removes the advantages you gain with abstractions. Even a function is an abstraction that when properly named encapsulates not only logic, but an idea that can be understood by a programmer by simply reading the name instead of spending the time to understand the logic.

Programs written this way are very linear, and code reuse is virtually impossible.

Introducing functions helps with code reuse and allows you to leverage abstractions, when compared to applications that do not utilize functions. At that point you've entered the realm of procedural programming. But there are limits to this as well.

A mishmash of global functions in a single file becomes difficult to manage and keep track of in your head, unless you organize functions into groups. At this point you start to see clear delineations of functionality appear, and you'll likely pull these function groups out into their own file. Then you see a need to bundle data along with these functions, so you start declaring global variables in these other library files. You've now reached the threshold where object oriented code becomes much more useful.

You can say this is a natural progression of low complexity to high complexity, however before writing a single line of code you need to determine how big this thing might get. Most applications grow beyond "a single file" very quickly, causing you to restructure the application multiple times, which slows down development unnecessarily.

Our challenge as engineers is to build an architecture that is appropriately complex for the problems we know need to be solved, and given our experience with how applications evolve. A majority of applications won't fit into a single file without making you go cross-eyed, which lends development to a minimum level of complexity (at least separate your concerns).

You need an architecture where you can easily add features and modify existing features, at the same time not building features and abstractions you don't yet need. That's the challenge.