Desenvolvendo N-fileira App. Em que direção?

Question

Assumindo que o que está a implementar uma história de usuário que requer mudanças em todas as camadas de UI (ou fachada de serviço) para DB.

Em que direção você move?

• A partir UI to Business Layer para Repositório de DB?
• DB para Repository to Business Layer para UI?
• Depende. (Por quê?)

Answer 1

A melhor resposta que eu vi a esse tipo de pergunta foi fornecido pelos caras objeto atômicas e sua Apresentador Primeira padrão. Basicamente é uma implementação do padrão MVP, em que (como o nome sugere) de começar a trabalhar a partir do Presenter.

Isto proporciona-lhe um objeto muito leve (uma vez que o apresentador é basicamente lá para dados marechal do modelo para a vista, e eventos do Vista para o modelo) que podem modelar diretamente o seu conjunto de ações do usuário. Ao trabalhar sobre o Presenter, a vista e Modelo são tipicamente definidos como interfaces, e escarnecido, para que o seu foco inicial está na definição de como o usuário está interagindo com seus objetos.

Eu geralmente gostaria de trabalhar desta maneira, mesmo que eu não estou fazendo um padrão MVP rigoroso. Acho que o foco na interação do usuário me ajuda a criar objetos de negócios que são mais fáceis de interagir com. Nós também usamos Fitnesse em casa para testes de integração, e eu acho que escrever as luminárias para Fitnesse ao construir a minha objetos de negócios ajuda a manter as coisas focado na perspectiva do usuário da história.

Eu tenho que dizer, porém, que você acabar com um ciclo TDD muito interessante quando você começa com um teste Fitnesse falhando, em seguida, criar um teste de unidade com defeito para que a funcionalidade, e trabalhar o seu caminho de volta até a pilha. Em alguns casos, eu também estou escrevendo testes de unidade de banco de dados, então não há outra camada de testes que começa a ser escrito, falhou, e passou, antes dos testes Fitnesse passar.

Answer 2

Se a mudança é provável, começar na frente. Você pode obter feedback imediato dos acionistas. Quem sabe? Talvez eles realmente não sabem o que querem. Vê-los usar a interface (UI, serviço, ou de outra forma). Suas ações pode inspirá-lo a ver o problema sob uma nova luz. Se você pode pegar mudanças antes da codificação objetos de domínio e banco de dados, você economiza uma tonelada de tempo.

Se os requisitos são rígidas, não é tão importante. Comece na camada que é provável que seja o mais difícil - risco endereço cedo. Em última análise, este é um daqueles "mais uma arte do que uma ciência" questões. É provavelmente uma interação delicada entre o design camada que cria a melhor solução.

Felicidades.

Answer 3

Eu faria isso se inferior, já que você vai ter alguns resultados que trabalham rápido (ou seja, você pode escrever testes de unidade sem uma interface de usuário, mas não pode testar a interface do usuário até que o modelo é feito).

Existem outras opiniões, no entanto.

Answer 4

Gostaria de começar a modelagem do domínio do problema. Criar classes relevantes que representam as entidades do Sistema. Uma vez que eu me sinto confiante com isso, eu tentaria encontrar um mapeamento viável para persistir as entidades ao banco de dados. Se você colocar muito trabalho para a UI antes de você ter um modelo do domínio, existe um risco significativo de que você precisa re-trabalho da UI depois.

Thinking of-lo, você provavelmente precisará fazer algumas atualizações para todas as camadas de qualquer maneira ... =)