Estrutura (orientada a arquitetura) versus estrutura de projeto orientada a recursos


14

O projeto, eu envolvi, tem uma estrutura de arquivo / pasta de projeto orientada à arquitetura:

Root
|____ Node1
    |____ Event Handlers
    |         |___ <all event handlers of project>
    |____ Events
    |         |___ <all events of project>
    |____ Request Handlers  
    |         |___ <all request handlers of project>
    |____ Requests
    |         |___ <all requests of project>
    |____ ...

É claro do ponto de vista arquitetônico do sistema (foi proposto pela equipe de desenvolvimento).

É uma estrutura orientada a recursos que foi proposta pela equipe de designers:

Root
|____ Feature #1
    |____ Event Handlers
    |         |___ <all event handlers of Feature #1>
    |____ Events
    |         |___ <all events of Feature #1>
    |____ Request Handlers  
    |         |___ <all request handlers of Feature #1>
    |____ Requests
    |         |___ <all requests of Feature #1>
    |____ ...

Essa variante está mais próxima dos designers e descreve claramente um recurso a ser implementado.

Nossas equipes começaram uma guerra santa: qual é a melhor abordagem. Alguém poderia nos ajudar e explicar contras e prós do primeiro e do segundo. Talvez haja um terceiro que seja mais útil e benéfico para nós dois.

Obrigado.


Não entendo nenhuma das estruturas - qual é a diferença entre eventos e solicitações (e, portanto, manipuladores de eventos e manipuladores de solicitações)?
quer

1
Pergunta muito clara - e neutra também!
Michael K

1
Da perspectiva da escalabilidade, a segunda abordagem deve ser bastante fácil de expandir horizontalmente.
CodeART

Respostas:


11

Eu votaria no segundo. Na primeira estrutura, os manipuladores de eventos para não FeatureAestão completamente relacionados aos manipuladores de eventos FeatureB. Parece que os desenvolvedores estão trabalhando em um recurso de cada vez e, se você estiver trabalhando em uma FeatureXsolicitação, é muito mais provável que precise ajustar um FeatureXmanipulador de solicitações do que, digamos, uma FeatureZsolicitação.

A propósito, adoro como você fez essa pergunta de um ponto de vista neutro.


1
+1 com uma ressalva: para pequenos projetos, o segundo resultará em uma estrutura de arquivos maior do que em arquivos para inseri-lo. Eu usaria o primeiro para eles.
Michael K

@ Michael, eu concordo, mas neste caso é um projeto grande.
Zzz

1
+1: e se você precisar conversar com um usuário / cliente, a terminologia poderá ser bastante consistente.
Steven Evers

4

Sempre me senti mais à vontade com a segunda abordagem, mas sempre tenho um "recurso" chamado geral ou comum para as classes verdadeiramente compartilhadas / base.

A abordagem dois mantém as coisas verdadeiramente separadas separadas, mas sem a área "comum" às vezes as separa em áreas nas quais elas não se encaixam bem.


+1 para comum e geral (cada projeto tem utilitários gerais, ferramentas ...)
Zzz

3

Por que os inventores de recursos se preocupam com os detalhes da implementação? Se essa é a separação entre os lados do argumento, acho que a resposta é clara. As pessoas que inventam idéias / recursos não determinam a estrutura de arquivos necessária aos implementadores.

Esse é um problema particularmente importante quando a implementação de um recurso abrange várias DLLs, exes, bancos de dados ou outras partes de software.


1
Pensei nisso, mas, sendo todas as outras coisas iguais, a segunda abordagem tem algumas vantagens filosóficas claras para todas as aplicações, exceto as mais triviais. No mínimo, é uma boa sugestão.
Robert Harvey

@ Robert Harvey: Se você está falando sobre a organização idealógica do projeto, precisaria pensar em uma nova resposta. No entanto, parece que eles estão falando arquivos contendo código ...
John Fisher

A chave é a separação de recursos em baldes distintos. Para todos os aplicativos, exceto o menor, você precisará de algum tipo de organização como esta, esteja se referindo a uma estrutura de pastas, estrutura de classes ou convenção de namespace.
Robert Harvey

1
@ Robert Harvey: E os problemas de construção e implantação? Que tal coisas mais simples, como simplesmente poder usar um IDE para escrever e depurar o código? Algumas dessas coisas devem ter um impacto poderoso nas estruturas de pastas.
John John Fisher

1

Tem que concordar com a segunda abordagem, dadas as duas opções. O primeiro parece apenas uma bolha amorfa. Pelo menos o segundo tem alguma forma.

Realmente depende do tamanho do projeto. Se os "recursos" forem grandes, cada um deles precisará de seu próprio balde distinto.


1

Não entendo a terminologia que você está usando, mas tentarei responder de qualquer maneira, pois as duas estruturas parecem ser a abordagem errada.

A menos que você tenha apenas alguns recursos, é necessário agrupá-los em categorias - e isso não parece ser atendido em nenhum dos designs (a menos que seja para isso que o Node1 se destina, mas o "todo X do projeto" sugere caso contrário, e me faz pensar em WTF - existe um Node2?)

Eu poderia considerar algo como isto:

Root
|____ Event Handlers
|   |____ Category A
|   |    |___ Feature #1 EHs
|   |    |___ Feature #2 EHs
|   |    |___ Feature #3 EHs
|   |
|   |____ Category B
|   |    |___ Feature #4 EHs
|   |    |___ Feature #5 EHs
|   |
|
|____ Events
|   |____ Category A
|   |    |___ Feature #1 Events
|   |    |___ Feature #2 Events
|   |    |___ Feature #3 Events
|   |
|   |____ Category B
|   |    |___ Feature #4 Events
|   |    |___ Feature #5 Events
|   |
|

Ou isto:

Root
|____ Category A
|   |____ Event Handlers
|   |    |___ Feature #1 EHs
|   |    |___ Feature #2 EHs
|   |    |___ Feature #3 EHs
|   |
|   |____ Events
|        |___ Feature #1 Events
|        |___ Feature #2 Events
|        |___ Feature #3 Events
|   
|____ Category B
|   |____ Event Handlers
|   |    |___ Feature #4 EHs
|   |    |___ Feature #5 EHs
|   |
|   |____ Events
|        |___ Feature #4 Events
|        |___ Feature #5 Events


Mas ambos estão fazendo suposições que podem estar completamente erradas - se você puder atualizar sua pergunta com mais detalhes, posso mudar de idéia. :)

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.