The trick is to figure out which parts of the system going into which part of the MVC (Model-View-Controller). In my experience, most of the work ends up in the Model part, which doesn't really care why or how you are looking at it. It's general code to do all of the interesting work without thinking about how you actually look at the data or how you tell it what you want to do. Above that is code to take those results to show it to us (the View) and other stuff to let us make it do things (the Controller). The V and C portions really aren't all that tough: they translate our requests into things the model can do, the translate what the model did back to our environment. They are really just adapters between our application and the Model.

Things don't end up in a single file because the idea is that there is no monolithic application. The Model should be able to use any View or Controller. It's not just a web application because it could be a SOAP thing, or a terminal interface, or something else. The Model should exist separately from a particular use of it.

Once those things are decoupled, people can work on the different layers and different parts without colliding with each other.