Existem duas estruturas principais de base de código que eu já vi quando se trata de estruturas MVC. O problema é que ambos parecem ter um bug organizacional que os acompanha.
MVC padrão
/controller
/model
/view
Problema: Não há separação de componentes relacionados (fórum, blog, usuário, etc.)
MVC modular
/blog
/controller
/model
/view
/user
/controller
/model
/view
/forum
/controller
/model
/view
Escolher o sistema baseado em módulo deixa você com um problema.
- Nomes longos (Forum_Model_Forum = forum / model / forum.php) (como Zend)
- O sistema de arquivos pesquisa usando
is_file()
para descobrir qual pasta possui o modelo de fórum? (Como Kohana)
Existem outras estruturas MVC que funcionam bem ao tentar separar módulos diferentes? Existem benefícios dessas estruturas que estou perdendo?
web-applications
mvc
web-framework
file-structure
Xeoncross
fonte
fonte
Respostas:
Experimentar:
Seus modelos são o coração da sua aplicação. Você deve projetá-los e codificá-los como um pacote independente. Os controladores são apenas clientes do seu modelo, que convertem a atividade do usuário em ações para o seu modelo. Uma visualização é apenas uma maneira específica de exibir dados do seu modelo. Se o seu aplicativo crescer, você poderá ir ainda mais longe ao separar os clientes do modelo:
Isso deve tornar óbvio que você pode ter vários clientes, que de uma maneira ou de outra, interagem com um único modelo.
fonte
;)
Encontrei a melhor estrutura para um MVC / HMVC Framework combinado. Principalmente, você precisa usar controladores / modelos / visualizações básicos ... mas para os componentes individuais dos módulos do curso ...
Então, na minha estrutura de estrutura MVC / HMVC, fica assim:
Além disso, se eu precisar adicionar módulos de bibliotecas, i18n ou helpers.
A convenção de nomenclatura é fácil, para controladores e modelos eu adiciono o sufixo _Controller e _Model. Para controladores e modelos dos módulos, também adiciono um prefixo com o nome do módulo, por ex. Perfil do controlador no módulo Usuário será nomeado como User_Profile_Controller.
Portanto, é muito fácil e rápido encontrar o que você precisa.
fonte
A nomeação sistemática das classes ajuda a evitar conflitos de nomeação entre componentes. Não é provável que a nomeação longa de classes imponha severas penalidades de desempenho. Acho esse esquema de nomes bastante útil ao codificar, porque é fácil ver o que vem de onde.
Isso depende muito de como o sistema foi implementado, mas a estrutura do sistema de arquivos geralmente segue uma convenção que permite acesso imediato ao componente correto sem extensas pesquisas no sistema de arquivos.
Aqui está um exemplo, suponha que o componente do fórum seja usado:
Informações:
Nome do controlador: index
$ controller_path = BASEDIR. 'module /'. $ component_name. '/ controller /'. $ controller_name. '.php';
Também é importante observar que existem literalmente centenas de consultas no sistema de arquivos ao inicializar um site típico, portanto, adicionar algumas não será prejudicial.
fonte
Eu tenho trabalho com sites que começaram com o primeiro "MVC padrão", mas eventualmente se tornaram o "MVC modular".
Se você está criando um site pequeno e não tem muita experiência, pode começar com o "MVC padrão". Se você já sabe que o site será muito complexo e grande, precisará se acostumar com o "Modular MVC"; será um pouco difícil no início, mas, eventualmente, você se acostumará isto.
fonte
Na verdade, estou trabalhando em uma estrutura e uso uma combinação de estrutura de diretórios baseada em módulo e de forma livre. Minha estrutura padrão para o código do site usando a estrutura é:
Você também pode ter uma pasta de módulo que não se relaciona a um controlador e, por padrão, há uma chamada Core que é usada para armazenar modelos em todo o site, como cabeçalho e rodapé. Isso para mim dá o melhor dos dois mundos. Você pode saber facilmente onde está o controlador, pois existe um controlador por pasta, mas para classes como modelos, você não precisa procurar onde estão os arquivos, pois estão em um diretório (que também mantém os nomes dos modelos mais limpos) .
A maneira como carrego arquivos é um pouco diferente, pois permito que o usuário configure os diferentes diretórios onde as classes podem estar. Analiso os diretórios inicialmente e armazeno todos os locais dos arquivos de classe em um arquivo json e depois o uso para procurar rapidamente todos os outros pedidos (mesmo que eu esteja procurando maneiras de melhorar isso).
fonte
A resposta para isso foi ditada pela proposta PSR-0, que todos os grandes sistemas estão começando a se adaptar ou adotaram agora.
A estrutura é:
Isso significa que não há nada que você possa fazer para corrigir nomes de arquivos longos:
Isso também significa que você deve usar arquivos estúpidos de maiúsculas e minúsculas em vez de todas as letras minúsculas (se você não usar bibliotecas de terceiros, não funcionará).
fonte
A solução Mathiases faz muito sentido E o uso de sua estrutura de pastas não impede que o conteúdo seja plugável, por exemplo, adicionar uma galeria / independente / pode se parecer com isso
Agora temos um "modelo" compartilhado e independentes, se necessário
fonte