Pergunta

Atualmente, estou construindo uma API que será utilizada por um webservice.

Eu queria saber o que os problemas de desempenho que eu poderia atender se eu construí minha API usando uma grande quantidade de métodos estáticos .

A idéia original era construir objetos de especialistas que atuam como serviços.

Em um ambiente de usuário único esta abordagem foi ótimo! Mas logo terá de porta a um ambiente de usuário multi / concorrente.

Que tipo de problemas de desempenho pode i encontrar com esse tipo de arquitetura?

Com os melhores cumprimentos,

Editar:

Os métodos estáticos não detêm variáveis ??estáticas e não têm efeitos colaterais. Eles simplesmente executar uma rotina normal, onde tudo é instanciado. (Ie. Vars e objetos)

Foi útil?

Solução

Não há nenhum efeito particular em simultaneidade. As mesmas regras são verdadeiras: mutação dados compartilhados concorrentemente é ruim. Se você tiver métodos de instância, mas eles fazem qualquer coisa não mutação, você está bem.

Há uma diferença na concepção geral embora - métodos estáticos deve ser quase sempre thread-safe (ou seja, você deve make -los thread-safe), enquanto que os métodos de instância geralmente não tem que ser (embora você deve documentar thread-segurança da sua classe).

Outras dicas

eu não estaria preocupado demais com problemas de desempenho (Knuth), eu estaria mais preocupado com questões de capacidade de teste e estado gestão em um ambiente de vários segmentos, principalmente para reduzir a complexidade de codificação e manutenção, que pode arrastar para baixo a projetar pior do que o problema de desempenho ocasional.

Você pode estática não simulados, imho assim o código que usa uma API que é baseado em métodos estáticos é relativamente não testável. Não realmente o que você está pedindo, mas por favor, pense sobre as pessoas que estão indo para usar sua API.

Você deve reduzir os pontos onde os dados compartilhados são mantidos entre os tópicos para o mínimo absoluto. Isso reduz as chances de problemas de segmentação. Você provavelmente vai perder um pouco de eficiência em fazer isso, mas você ganha muito em facilidade de codificação e manutenção. Imaginar o quão difícil seria para escrever e testar um aplicativo ASP.NET, se todas as páginas eram estáticas. Seria um pesadelo. Você pode encontrar-se indo por esse caminho como seus ganhos API apresenta ao longo do tempo.

Além disso, use um quadro DI decente (I liek Unity, pode ser a melhor coisa para sair de P & P).

Você não tem que se preocupar com as variáveis ??locais em um método estático. Cada segmento tem sua própria pilha e cada chamada para o método irá criar uma cópia separada da variável local na pilha. Por exemplo, os métodos SQLHelper MS prever na sua aplicação bloqueia usar esta mesma técnica.

A grande questão é variáveis ??estáticas. Eu praticamente nunca use variáveis ??estáticas, eu não tive a necessidade de.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top