Precisa de conselhos sobre solução em camadas, separação de interesses, etc

Question

Nós temos uma aplicação em camadas, ou pelo menos é no processo de transição para um, repartidos da seguinte forma:

• de interface (interface de utilizador ou aplicação da interface, ou seja. Webservice, etc.)
• A lógica de negócios
• Acesso a dados

Para fazer o resto desta questão mais concreta, vou descrever uma instância específica.

Nós temos uma interface de usuário, que tem um objeto controlador por trás dele (a camada de lógica de negócios). Este controlador comunica com a base de dados através de um outro objecto (a camada de acesso dados).

Em um determinado contexto, a interface do usuário permite que o usuário escolha um empregado para amarrar a operação que está sendo feito para. Uma vez que existem regras sobre quais os funcionários do usuário (bem, qualquer fora do mundo do controlador realmente) pode escolher, o controlador fornece duas coisas para isso:

• uma propriedade legível contendo uma lista de funcionários disponíveis para escolher
• a leitura / propriedade gravável que contém o empregado atualmente escolhido

A interface de usuário pode ler a lista e usá-lo para preencher um combobox.

Na versão 1 desta aplicação, a caixa de combinação contém o número de identificação do empregado + o nome do empregado.

Tudo está bem ...

... até a versão 1.1, uma correção de bug. Um usuário reclama que ele não pode escolher entre Jimmy Olson e Jimmy Olson porque o aplicativo não faz com que seja fácil o suficiente para ele saber qual é qual. Ele sabe que é um Jimmy no departamento de vendas, e outro no departamento de desenvolvimento, de modo a correção para esta versão 1.1 é simplesmente tack em um o nome do departamento na combobox barra +. Na versão 2 que se optar por substituir a caixa de combinação com uma caixa de combinação que tem suporte da coluna, removendo a barra, mas em 1.1, isso é o que é escolhido de forma a minimizar o risco de novos bugs.

Em outras palavras, a caixa de combinação deverá conter:

• 1 - Jimmy Olson / Vendas
• 2 - Jimmy Olson / Desenvolvimento
• • outras pessoas

No entanto, o código de interface com o usuário não tem nenhum código SQL ou qualquer maneira de se apossar desse departamento, e, portanto, temos que ir para o controlador e olhada no código lá. O controlador não precisa do departamento, e para ser honesto, ele não precisa mesmo o nome do empregado, o número de identificação é suficiente, então não há nada no controlador que pede ou faz nada para o departamento. Então, nós temos que ir para a camada de acesso a dados e mudar o SQL lá.

Esta solução francamente cheiros.

Se houver várias interfaces para este controlador, com exigências diferentes, temos três soluções possíveis:

1. Alterar a camada de acesso a dados para atender a (crescente diversas /) necessidades de múltiplas interfaces (2 camadas de distância), o que significa que todas as interfaces possivelmente irá obter todos os dados de que precisam, mas eles também obter todos os dados necessário para qualquer uma das outras interfaces
2. Adicionar algo que permite que a interface de usuário dizer a camada de acesso a dados (ainda 2 camadas de distância) o que ele precisa
3. De alguma forma fazer a interface com o usuário camada de se apossar dos dados necessários sem alterar quer a camada de controlador ou do acesso em causa, isso soa como precisamos de mais código de acesso a dados, em algum lugar.

Nenhuma das soluções acima se sentir bem.

O que eu estou querendo saber é, estamos completamente fora do curso? Como você faria isso? Há uma solução quarto e quinto abaixo dos 3 acima?

Por esta pergunta: de Preocupações , a resposta aceita contém esta citação:

A separação de interesses é manter o código para cada uma destas preocupações separam. Alterando a interface não deve exigir a alteração do código de lógica de negócios, e vice-versa.

Será que isso simplesmente significa que todos / camada de acesso a dados do controladordeve nos fornecer é aquilo de que necessita para fazer o seu trabalho (isto é. os números dos empregados), e, em seguida, a interface do usuário deve ir falar com o banco de dados e pedir mais informações sobre esses funcionários específicos ?

Answer 1

A forma como eu vejo, você tem duas possibilidades:

1. Faça com que as camadas inferiores enviar até todas a informação que têm sobre um pessoa, possivelmente como um documento XML, embora muitos dos consumidores de que a informação não precisa de tudo.
2. Fornecer APIs para o nível mais elevado camadas para aprofundar e obter o informação de que necessitam. Assim, no caso você dá, tem um método que a interface pode pedir o negócio camada de pedir a camada de banco de dados para o departamento dado o ID de usuário.

Ambos têm vantagens e desvantagens. O primeiro expõe muito mais informações, possivelmente para os consumidores que não têm qualquer direito a essas informações. A segunda passa muito menos informações por transação, mas requer várias operações. O primeiro não requer uma alteração na API toda vez que tiver mais informações, mas muda o XML. O segundo mantém a interface de APIs existentes a mesma, mas fornece novas APIs como a mudança necessidades. E assim por diante.