"MVC" is at least a half dozen different patterns at this point, and at least one - the one the closeparen is talking about, rendering responses to incoming requests out parts of a data store - is pretty common in Go.

What's different is that the "model" is often e.g. a bare sql.DB and not an object repository, and the "view" is a template called directly by the controller, but "MVC" - even this kind, which isn't the original kind - doesn't have to be an auto-wired DI interface-laden mess. PHP and Java just made it that way.

Maybe it would pay to be more specific, since "MVC" can mean a lot of things. We have requests come into handlers, which map between wire and internal representations. They invoke controllers, which implement the business logic and call gateways and repositories. Repositories wrap storage clients and gateways wrap HTTP or gRPC clients.

Do you not do this? What do you do instead? I guess I can see how testing would be less painful with fewer layers, but at the cost of the production code becoming more entangled.

Assuming the parent is being genuine in asking for help, I don't think is a very constructive response.