Q:

Boas práticas para MVC em PHP

Estou me aprofundando sobre o uso de MVC utilizando PHP, e após ver algumas aulas e artigos na internet me surgiram algumas dúvidas de utilização, já que encontrei aulas que apresentam de forma diferente o mesmo caso. Eu sei que não existe a forma perfeita, mas gostaria de um esclarecimento de qual seria a melhor prática a se adotar.
1°) A conexão com o BD deve ser feita através do controller, do model ou de algum outro arquivo de configuração ? - encontrei artigos em que se faziam em ambos.
2°) Tenho que criar um model por tabela? - Digamos que eu tenho a Tabela1 e a Tabela2, e preciso de um SQL que relaciona as duas, eu tenho que ter um model separado para cada uma delas, ou no model da Tabela1 eu faço uma consulta com JOIN entre elas?
3°) Tenho um botão em uma view que retorna um formulário preenchido por exemplo, esse "código" do formulário (sendo ele em HTML com dados do BD), é montado no model, controller ou uma view que tenha apenas esse formulário?
4°) A pasta com arquivos CSS, JS e Imagens, possui um local específico, tipo dentro da pasta app ou da pasta View?

A:

Não existe esse negócio de boas práticas. Existe certo ou errado para cada situação. Só a experiência qualificada, mais que quantificada, dará base para conseguir fazer melhor.
A maioria dessas aulas por aí são receitas de bolo que tolhem a criatividade da pessoa, vendem a ideia de que só existe uma forma certa de fazer e muitas vezes contém diversos erros.

Onde vai a conexão depende da arquitetura geral. Alguns dirão que é no model (em geral, não dentro da classe de dados), não está errado, outros dirão que o modelo mesmo são só as classes de dados. Dificilmente a conexão estará no controlador. Não vejo muito sentido nisto, não consigo imaginar um motivo para fazer isto. Se usará um arquivo de configuração ou não, é uma decisão que nada tem a ver com MVC.
Model é uma camada, então em tese tem um por aplicação (não é tão simples assim, pode haver models diferentes). Se está falando de classe, pode ser uma por tabela do banco de dados. Mas não é necessário reproduzir isto. Podem existem classes de modelo que são montadas por dados combinados de várias tabelas ou outras informações. Pode não incluir alguma tabela. No caso de um join pode ser interessante ter uma classe para esse relacionamento.
O botão gera uma ação para o controlador. Este controlador consultará o modelo, e no fim gerará uma visão. Não sei se entendi a dúvida, mas isto é o MVC, é essencialmente assim. Só não gerará uma visão quando deve apresentar nada. Só não consultará o modelo se não precisa de nenhum dado que está lá (lembrando que o modelo pode ter informações além do banco de dados). Então é montado pelo conjunto das três coisas, cada uma fazendo sua parte.
Organização de arquivos você faz do jeito que achar melhor, o MVC não determina onde por. Padrões só determinam o que é relevante para resolver um problema específico. Você pode mudar o que quiser no padrão se não mudar o resultado, se não criar problema para a solução. Padrões até podem ser consideradas receitas de bolo, mas como toda receita não precisa seguir certinho. É claro que se não sabe cozinhar terá mais dificuldade em fazer certo se fugir na receita. Por isso o meu conselho é aprender cozinhar.

Se tiver dúvidas mais específicas, mais concretas para o seu caso, vá fazendo.

A:

MVC é um padrão de projeto.
Padrões de projeto devem ser empregados para resolver um "problema" de maneira comum e padronizada, permitindo aplicar soluções comprovadas e/ou padronizar arquiteturas permitindo que uma equipe trabalhe de forma homogênea.
Desta forma, o padrão de projeto MVC foi criado para resolver o problema de organização lógica de um projeto, utilizando separação por responsabilidades, assim, o (M)odelo fica responsável por manipular dados e/ou a parte lógica da aplicação, a (V)isão fica responsável por aplicar toda a lógica de saída de informações - podendo ser uma "tela" em HTML ou a geração de respostas XML ou JSON; por fim o (C)ontrolador fica responsável por orquestrar modelos e visões por funcionalidade, sendo ele quem recebe as requisições de ação, identifica quais modelos devem tratar os dados para uma requisição e quais visões devem retornar a saída/resposta da requisição.
É possível ainda a aplicação de outros padrões de projeto em conjunto para resolver diversos "problemas" - Front Controller para centralizar os tratamentos de requisição, aliado ao Dispatcher para identificação e instanciação do controlador correto a tratar uma requisição; DAO/ORM/Active Records para tratar manipulação de dados persistentes; Services Layer para separação agnóstica da lógica da aplicação, etc.
Veja portanto que existem sim necessidades de aplicar corretamente os conceitos.
Em relação às suas perguntas enumeradas

o Modelo deve tratar de dados, esta é a definição, não acho correto no modelo, por exemplo, realizar a conexão com o banco, o ideal é utilizar injeção de dependência para este fim com uma classe especializada em lidar com as questões de baixo nível do banco.
Criação de um Modelo por tabela implica, provavelmente, na aplicação do padrão de projeto Active Record. O que não lhe impede de, por exemplo, ter modelos que lidem com dados em sessão, como o Modelo de um carrinho de compras, ou modelos que manipulem coleções em arrays. O ideal é que um modelo não tenha lógica de tratamento de requisições ou de visão.
Vou repetir praticamente toda a resposta do @Maniero: 
O botão gera uma ação/requisição para o controlador. Este controlador irá trata a requisição, podendo validar dados de entrada, mas não manipular estes dados, passa-os então para o modelo (consultar, alterar dados etc). Após o(s) modelo(s) manipularem os dados, o controlador envia o(s) modelo(s) para uma visão e esta se encarrega de gerar a saída (uma tela, um relatório, um XML, etc). Isto é o fluxo padrão do MVC. Só não gerará um visão quando não tem que apresentar nada. Só não consultará o modelo se não precisa de nenhum dado que está lá (lembrando que o modelo pode ter informações além do banco de dados). Então é montado pelo conjunto das três coisas, cada uma fazendo sua parte.
Em geral estes arquivos devem estar em uma pasta de acesso público para o cliente (navegador) ou subpastas desta pasta. Porém exatamente como você organiza fica a critério de um bom estudo de adequação e (gosto) seu ou de sua equipe.

Minha sugestão seria que você, além de estudar os conceitos dos padrão de projeto, estudasse e utilizasse um framework consolidado, que já implementa boa arquitetura de software utilizando estes padrões. Minha lista de preferências seria: Laravel, Symphony, Zend Framework; não conheço mas são frameworks consolidados com boa comunidade: Phalcon, Yii.

