Olá Sidnei, testar controllers é algo bem problemático como você mesmo viu, recomendo escrever um teste de sistema para fazer isso, da uma olhadinha na formação de testes de software principalmente no curso de Selenium, que lá você consegue base para fazer isso.

http://alura.com.br/cursos-online-testes

Espero ter ajudado. Abraços !

Oi, Renan, eu na verdade não estou testando controllers. A ideia foi fazer um projetinho simples, onde eu pudesse testar comandos do php ou codeigniter.

A dúvida maior aqui é sobre o MVC e práticas de programação.

Mas é claro que ajudou sim. O curso de Selenium fica pra daqui a pouco...

Abraço!

Oi Sidnei,

Se entendi bem, você criou uma aplicação apenas para testar o uso e como algumas funções do PHP/CodeIgniter são executadas, é isso?

Não vejo, pelo menos no descrito, onde você possa estar quebrando o MVC. Imagine que seu Controller Teste será usado para receber todas as requisições do usuário. O papel dele, é repassar essa requisição (os dados dela) para o cara que irá de fato executar a lógica do negócio, que é o Model.

O que você pode fazer para deixar o seu projeto mais "MVC Like" é colocar os comandos, o array de comando, para executar em uma outra função que será chamada pela sua função teste/index algo como executaComando em um arquivo comandos.php. Algo do gênero, é apenas a ideia.

Se fizer sentido, veja se ajuda. Qualquer dúvida estou a disposição.

Abraço

Paulo, obrigado pelos esclarecimentos. Gostei muito da tua explicação. Compreendeste exatamente o que fiz.

Mas ainda não vou encerrar porque ficou uma dúvida, se puderes esclarecer:

Eu associava model ao uso do banco de dados e pela tua explicação o model é praticamente o negócio, as regras mesmo.

Ou seja, eu poderia(deveria) ter funcionalidades no model, mesmo que não necessite usar o banco de dados.

É isto?

Mais uma vez, obrigado,

Abraço

Oi Sidnei, exatamente. O Model é a camada "pós" controller. Se você precisa ir no banco, o arquivo com as funções de banco podem fazer parte do modelo, mas também arquivos que tem apenas lógica de negócio são considerados parte do modelo.

Um conceito que você verá em breve em outros cursos ou mesmo linguagens, é o conceito de Objeto de Acesso a Dados, geralmente vemos o conceito em inglês Data Access Object ou simplesmente DAO. Um DAO está geralmente ligado a Orientação a Objetos, mas podemos aplicar o conceito de separação de arquivos por responsabilidade, assim, o arquivo que faz apenas acesso ao banco, pode, conceitualmente, ser chamado de DAO.

Os arquivos que cuidam da parte de negócio são geralmente chamados de Service ou Business. Como falei, seu arquivo de lógica pode ser um arquivo responsável pelo serviço (negócio) da aplicação.

Resumindo, em geral, adicionamos ao Model da aplicação, tanto os Service's como os DAO's.

Falou, Paulo.

Entendi tudo nesta troca de mensagens.

Se não for te chatear muito, para ficar "MVC like", em se tratando de CodeIgniter ficaria na pasta model de application, certo?

Tou finalizando, se me responder mais esta é um baita lucro pra mim.

Abraço

Ali em cima me referi que a função comando.php ficaria na pasta model.

Opa, isso mesmo, o CodeIgniter já separa essa pasta para facilitar as chamadas por lá.

Tente sempre usar o esquema do framework, pois assim você evita problemas de configuração.

Sucesso e abraço.