camadas estáticos em uma aplicação Java web

Question

Estou construindo um pequeno site para se divertir / aprendizagem utilizando um Web bastante normal / Serviço / Acesso a dados em camadas design.

Para me salvar de constantemente ter que criar instâncias do meu serviço as classes da camada de acesso camada / dados, eu fiz os métodos em todos eles estática. Eu não deveria ter problemas de simultaneidade como eles usam variáveis ??locais etc e não compartilhar quaisquer recursos (as coisas são bastante simples para isso no momento).

Tanto quanto eu posso ver o único trade-off para isso é que eu não estou realmente seguindo uma abordagem OO verdade, mas em seguida, novamente ele mantém o muito mais limpo código.

Há alguma razão isso não seria uma abordagem viável? Que tipo de problemas poderiam surgir mais tarde? Seria melhor ter uma classe "fábrica" ??que pode me devolver instâncias das classes de serviço e camada de dados, conforme necessário?

Answer 1

Desvantagens:

• Você não será capaz de testes de unidade de gravação como você não será capaz de escrever o acesso a dados de simulação / lógica de negócio objetos de teste contra.
• Você vai ter problemas de simultaneidade como diferentes segmentos tentarem acessar o código estático, ao mesmo tempo -. Ou se você usar sincronizado métodos estáticos que você vai acabar com tópicos fila para usar os métodos estáticos
• Você não será capaz de usar variáveis ??de instância, o que irá tornar-se uma restrição como o código se torna mais complexo.
• Será mais difícil de substituir elementos das camadas de negócios ou de acesso a dados se você precisa.
• Se você pretende escrever a sua aplicação desta maneira você seria melhor fora de usar uma linguagem projetada para trabalhar desta forma, como PHP.

Você seria melhor fora de ir para as classes da camada de acesso negócio / dados não-estáticos por meio de:

• Usando o padrão Singleton (criando uma única instância de cada classe e compartilhá-los entre threads) ...
• ou criar instâncias das classes em cada segmento como e quando eles são necessários.

Tenha em mente que cada usuário / sessão conectado ao seu aplicativo será executado em seu próprio fio -. Por isso a sua aplicação web é inerentemente multi-threaded

Answer 2

Você sabe que os passeios no parque de diversões onde eles dizem "por favor, mantenha suas mãos e pés dentro do passeio em todos os momentos"? Acontece que o passeio é muito mais divertido se você não faz. A única real trade-off é que você não está realmente seguindo uma verdadeira guarda-as-mãos-e-pés-dentro-do-ride-em-todos-tempos se aproximam.

O ponto é este - há uma razão que você deve seguir uma "abordagem OO verdade", assim como há uma razão para manter as mãos e os pés dentro do passeio - é muito divertido até que você começar a sangrar em todos os lugares.

Answer 3

A maneira como você descrevê-lo, esta não é a abordagem "errado" per se, mas eu realmente não vejo o problema que você está tentando evitar. Você não pode simplesmente criar uma única instância desses objetos de negócios quando o servidor inicia e passá-las para seus servlets, conforme necessário?

Se você está pronto para jogar OO para fora da janela que você pode querer verificar o padrão Singleton também.

Answer 4

Eu realmente não vejo a vantagem para o seu projeto, e há muitas coisas que podem dar errado. Está a poupar uma linha de código, talvez? Aqui estão algumas desvantagens para a sua abordagem:

• Você não pode facilmente substituir implementações de sua lógica de negócio
• Você não pode definir variáveis ??de instância para facilitar quebrando a lógica em vários métodos
• O seu pressuposto de que as questões multi-threaded não irá surgir é quase certamente errado
• Você não pode facilmente zombar deles para testar

Eu realmente não ver que a omissão de uma linha de código está comprando nada.

Não é realmente um problema "OO Design", mas mais de uma adequação. Por que você está mesmo usando Java de uma maneira tão processual? Certamente PHP seria mais apropriado para este tipo de projeto (e realmente lhe poupar tempo por não ter para compilar e implantar).

Gostaria apenas de fazer a sua camada de negócios não-estático; ele irá torná-lo muito mais fácil para manter, alterar e evoluir a sua aplicação.

Answer 5

Você pode ter unidade de teste de dificuldade seus objetos com este tipo de arquitetura. Por exemplo, se você tem uma camada de objetos de negócios que fazem referência a sua camada de acesso a dados estáticos, que poderia ser difícil para testar a camada de negócios porque você não será capaz de facilmente usar objetos de acesso a dados simulados. Ou seja, ao testar a sua camada de negócios, você provavelmente não vai querer usar os métodos "reais" na camada de acesso a dados porque eles vão fazer alterações indesejadas em seu banco de dados. Se a sua camada de acesso a dados não era estático, você poderia fornecer objetos de acesso a dados simulados para sua camada de negócios para fins de teste.

Answer 6

Gostaria de pensar que você terá problemas de concorrência com todos os métodos estáticos com vários usuários. A camada web vai enfiar a usuários simultâneos. todos os seus métodos estáticos pode lidar com isso? Talvez, mas não eles constantemente ser bloqueado na fila as solicitações em fila indiana? Eu não tenho certeza, nunca tentou a sua ideia.