Projetando interfaces do módulo

5

Estou estudando engenharia de software e uma coisa que realmente estou tentando melhorar é minha habilidade em arquitetura de software. Minha pergunta é bem ampla, então tentarei explicar isso com um exemplo.

Suponha que você tenha uma camada de modelo e uma camada de serviço. O modelo gerencia várias entidades (como usuários, produtos, pedidos, campains etc.). Os serviços fornecem recursos, como avaliação da eficiência de uma campanha , e usam vários módulos da camada de modelo para acessar os dados necessários.

Como e quando você especifica essas dependências? Eu vejo as seguintes possibilidades:

  • Permitir acesso geral a todos os modelos. Essa é a abordagem adotada em muitas estruturas MVC, nas quais os controladores podem acessar qualquer classe de modelo.

    Pro: Você não precisa especificar as dependências, o desenvolvedor que escreve o controlador é muito flexível.
    Contra: Se você quiser testar um serviço , você realmente não sabe qual modelo você tem que zombar porque o serviço poderia usar tudo. Essas dependências implícitas também podem tornar a manutenção uma dor.

  • Os serviços especificam os modelos requeridos explicitamente. Sistemas de gerenciamento de dependências como o requirejs ou o CommonJS requerem trabalho dessa maneira.

    Pro: Nenhuma dependência implícita simplifica a manutenção Contra: A simulação é impossível. Ao projetar o módulo, você precisa saber exatamente o que o módulo precisará. Se mais tarde você perceber que precisa de outra interface, precisará alterar a arquitetura.

  • Especifique interfaces explícitas que serão fornecidas ao serviço. Qualquer pessoa que insta o serviço terá que fornecer implementações das interfaces. Eu acho que a injeção de dependência funciona dessa maneira, embora a injeção seja automatizada lá.

    Pro: Nenhuma dependência implícita simplifica a manutenção, O teste é simplificado, porque você sabe exatamente o que deve ser reproduzido.
    Contra: Ao projetar o módulo, você precisa sabe exatamente o que o módulo precisará. Se mais tarde você perceber que precisa de outra interface, precisará alterar a arquitetura.

Em teoria, injeção de dependência parece ser o melhor caminho. Mas é prático especificar cada requisito? Quão refinado deveria ser? Por entidade? Agrupá-los? Ou uma dependência por "coisa que você pode fazer com uma entidade"?

Há possibilidades demais e gostaria de receber alguns conselhos do mundo real.

    
por Yogu 16.07.2014 / 19:39
fonte

1 resposta

2

Um módulo verdadeiramente independente exporia a API para criar objetos que ela expõe e cada um desses objetos exporia uma interface clara para o que o objeto deve fazer.

Em vez de qualquer API gigante em algum lugar. Por exemplo, jQuery - um objeto porque faz uma coisa. jQueryUI não é um objeto, mas oferece objetos individuais como widgets.

Então, a partir de um cliente (código), o que o módulo faz é bem documentado. Etapas complexas para criar os objetos são simplificadas.

Como e quando você especifica essas dependências?

O código do cliente deve estar apenas adicionando o módulo como uma dependência. Se o módulo tiver outras dependências, elas precisarão ser resolvidas à medida que a dependência do módulo for resolvida. (RequireJS, Dependências Maven)

Injeção de Dependência

Isso é diferente da dependência de código, como você observou. O modelo deve ser injetado na interface do módulo. Seus objetos de serviço também podem ser injetados aqui, mas nesse caso são seus serviços que injetarão o Modelo e os objetos de serviço podem ser criados somente a partir do seu MyModuleFactory (Impl).

O código do cliente que você injetou no MyModuleFactory. A cadeia de injeção será resolvida no caminho.

Ponto específico sobre modelo e serviços - modelo não anêmico

Os serviços podem parecer uma boa ideia, mas isso se torna um problema. Casos de check-out contra isso.

Modelo de domínio anêmico

    
por 12.08.2014 / 21:25
fonte