Como você organiza sua estrutura MVC enquanto suporta módulos / plugins? [fechadas]

17

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?

— Xeoncross
fonte

1

Eu também gostaria de acrescentar que quero uma estrutura compatível com PSR-0, para que também possa usar bibliotecas como Zend e Doctrine, se necessário.

— Xeoncross

9

Experimentar:

/blog 
    /controller
    /view
/user
   /controller
    /view 
/forum
    /controller
    /view
/model
    User
    BlogPost
    Comment
    ....

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:

WebClient
    /blog 
        /controller
        /view
    /user
       /controller
        /view 
    /forum
        /controller
        /view
CommandLineClient
    delete_spam_posts_script
RestApiClient

/model
    User
    BlogPost
    Comment
    ....

Isso deve tornar óbvio que você pode ter vários clientes, que de uma maneira ou de outra, interagem com um único modelo.

— Mathias Verraes
fonte

+1 porque concordo totalmente com a sua explicação dos componentes do MVC e como eles devem funcionar. No entanto, o objetivo de um módulo é que você pode importar os módulos criados por outros usuários, portanto, ter os modelos fora do caminho do módulo torna menos "arrastar e soltar". No entanto, seu método faz muito sentido para aplicativos que não usam plug-ins ou módulos externos.

— Xeoncross

@Xeoncross isso é verdade, eu realmente não levei em conta a reutilização aqui. Se isso for um requisito, você poderá realmente dar um passo adiante e ter, por exemplo, um módulo 'Usuário' que agrupe o modelo de usuário com seu controlador e um módulo Blog que agrupe o modelo BlogPost e Comment com seus controladores. Como sempre: depende do contexto :-)

— Mathias Verraes

2

;)

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:

/application
  controllers/
  models/
  views/
  modules/
    blog/
      controllers/
      models/
      views/ 
    user/
      controllers/
      models/
      views/
    forum/
      controllers/
      models/
      views/

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.

— Shogun
fonte

1

Problema: Nomes Longos (Forum_Model_Forum)

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.

pesquisas no sistema de arquivos (qual pasta possui o modelo de fórum?).

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 componente: forum
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.

— Lea Hayes
fonte

Na verdade, os back-ends não são como aplicativos do lado do cliente que precisam ser inicializados rapidamente; eles podem levar o tempo necessário para configurar o tempo de execução corretamente. Bom ponto.

— Patrick Hughes

0

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.

— umlcat
fonte

0

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 é:

/Configuration (stored a bunch ini files for security related information like passwords)
/Functions (stores file(s) with standard procedural functions)
/Libraries (general use classes)
/Models (all models go here)
/Modules (each module refers to one controller
/Modules/Site (controller class store in this folder if there is a controller)
/Modules/Site/Views (views for the controller)

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).

— ryanzec
fonte

0

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 é:

\Doctrine\Common\IsolatedClassLoader => /Doctrine/Common/IsolatedClassLoader.php
\Symfony\Core\Request => /Symfony/Core/Request.php
\Zend\Acl => /Zend/Acl.php
\Zend\Mail\Message => /Zend/Mail/Message.php

Isso significa que não há nada que você possa fazer para corrigir nomes de arquivos longos:

$controller = new \Blog\Controller\Archive => /Blog/Controller/Archive.php

/Blog
    /Controller
        Archive.php
    /Model
    /View
/User
    /Controller
    /Model
    /View
/Forum
    /Controller
    /Model
    /View

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á).

— Xeoncross
fonte

0

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

WebClient
    /blog 
        /controller
        /view
    /user (uses /model/User/)
       /controller
        /view 
    /forum
        /controller
        /view
    /gallery
        /controller
        /view
        /model
CommandLineClient
    delete_spam_posts_script
RestApiClient

/model
    User
    BlogPost
    Comment

Agora temos um "modelo" compartilhado e independentes, se necessário

— Timo Huovinen
fonte