Ao projetar um sistema, é melhor praticar o design em torno da estrutura que você usará?

37

Ao desenvolver um sistema ou aplicativo que você planeja usar com uma determinada estrutura, a melhor prática é projetar o sistema sem a estrutura em mente, ou é melhor projetar o sistema com a mentalidade "bem, a estrutura teria um tempo mais fácil com isso ".

    
por Robert Pounder 12.04.2017 / 11:50
fonte

3 respostas

51

Seu design deve atender às necessidades dos clientes, tanto quanto eles puderem. Lembre-se de que o design inclui pequenas coisas como:

  • Experiência do usuário
  • Funcionalidade
  • Como partes do seu aplicativo se comunicam (com ele mesmo ou com entidades externas)

Nenhuma dessas coisas deve ser ditada pelo framework. Se estiver claro que você estará lutando com sua estrutura para atingir essas metas, escolha um novo framework que o ajude a alcançar esses objetivos antes de começar a escrever o código.

Depois de escolher um conjunto de ferramentas apropriado (a estrutura é uma ferramenta), recomendo usar as ferramentas da maneira como elas são projetadas para serem usadas. Quanto mais você se desviar do design da estrutura, mais aumentará a curva de aprendizado para sua equipe e maiores chances de algo dar errado.

Em resumo

  • Design para seus usuários
  • Escolha as ferramentas apropriadas para realizar seu projeto
  • Use suas ferramentas da maneira como elas são projetadas para serem usadas

Outros pensamentos:

Depois de mais de 20 anos de engenharia de software e usando vários frameworks, aprendi algumas lições. Todos os frameworks são uma faca de dois gumes: ambos restringem e ativam. A questão de decidir seu framework antes de olhar para os grandes 3 que eu mencionei acima é que você pode estar comprometendo uma boa experiência do usuário por uma medíocre (na melhor das hipóteses). Ou você pode ser forçado a desviar-se do design de estruturas para realizar algumas funcionalidades específicas.

    
por 12.04.2017 / 13:54
fonte
27

As estruturas influenciam naturalmente o design de módulos específicos e de subsistemas (como um front-end de GUI). Como a outra resposta mencionada, você terá dificuldades se você se encontrar lutando contra a (s) estrutura (s) escolhida (s).

No geral, no entanto, você deve evitar que qualquer estrutura ou tecnologia única dite ou dirija o "quadro geral" de sua arquitetura geral do sistema. A maioria dos frameworks de aplicativos de propósito geral não encoraja isso, então se você se encontrar escrevendo todo o seu sistema em torno de uma estrutura, provavelmente estará fazendo algo que os autores dessa estrutura não pretendiam.

Você provavelmente usará muitos frameworks diferentes para resolver problemas diferentes; À medida que seu sistema se torna mais complexo, você precisa ter cuidado para não construir The Big Ball Of Mud . Sempre que possível, mantenha seu sistema modular e fracamente acoplado. Alguns frameworks podem ser mais bem mantidos atrás de abstrações, escrevendo wrappers e adaptadores que 'escondem' os fluxos de trabalho específicos do Framework para longe de outros componentes. Os kits de ferramentas da GUI tendem a servir apenas a funcionalidade GUI front-end, portanto, esses módulos da GUI devem ser mantidos longe do resto do sistema.

Estruturas de uso geral (como estruturas de interface do usuário, estruturas de camada de dados, etc.) não existem para prescrever a arquitetura completa do seu sistema - no máximo, podem prescrever o design de um componente ou módulo; por exemplo, algumas tecnologias GUI são voltadas para padrões MV * específicos.

A arquitetura geral do seu sistema deve ser impulsionada principalmente por seus requisitos de negócios . Você pode se deparar com uma ferramenta específica (por exemplo, uma ferramenta de middleware de mensagens ou uma estrutura ORM) para unir tudo, mas se você tiver encapsulado a estrutura em uma abstração como uma classe de 'serviço', É menos provável que você esteja sendo limitado por essa estrutura quando encontrar suas limitações.

Tente manter em mente o seguinte para o seu design geral:

por 12.04.2017 / 14:19
fonte
7

Sim, você deve manter o mais próximo possível do que a estrutura "diz" para você fazer.

A razão é simplesmente que quanto mais você se aproxima do modo de pensar dos frameworks, mais fácil você será capaz de conversar com outros desenvolvedores sobre seus problemas / ideias que também usam esse framework.

Você aumenta a interoperabilidade e a facilidade de uso para outras pessoas que o usam mais tarde, você entenderá e incorporará tutoriais ou soluções comuns melhor se mantiver a filosofia subjacente de tudo o que estiver usando.

A única boa razão pela qual eu posso pensar em por que você iria "quebrar" a estrutura é que você absolutamente precisa de algo que não pode fornecer, dada a configuração / aplicação de princípios "padrão". Mas então, pode não ser o framework certo para começar.

Basicamente, isso também pode ser aplicado a outras decisões. Você deve usar a linguagem que está usando da maneira que deve ser usada, porque torna as coisas mais fáceis se você estiver falando a mesma língua que todos os outros.

    
por 12.04.2017 / 13:15
fonte