A ASP.NET MVC é lenta em comparação com a abordagem tradicional?

4

Eu criei três pastas no Explorador de Projetos de qualquer IDE que eu use. Eu os nomeio: Camada de Aplicativos, Camada de Negócios e Camada de Dados. A camada de aplicativo armazena todas as informações da interface do usuário, a camada de negócios armazena todas as classes que lidam com lógica de negócios e a camada de dados mantém as classes para conectividade e consultas de banco de dados.

Eu sou novo no padrão MVC e quando tentei no VS2010 com o ASP.NET, achei muito mais complicado com todos os tipos de pastas aninhadas criadas. Eu já estava separando a lógica e a interface do usuário no meu estilo antigo. O que diferiu no MVC é que você pode usar o roteamento para chamar métodos diretamente via URL (corrija-me se eu estiver errado), mas, nesse caso, presumo que o desempenho do aplicativo MVC seja mais lento. É apenas uma sobrecarga para chamar um método via URL e que o método consulta o banco de dados.

O desempenho da ASP.NET MVC não é um pouco lento? Mesmo que a capacidade de gerenciamento seja boa, mas a curva de aprendizado também é muito íngreme?

    
por RPK 28.04.2011 / 16:21
fonte

3 respostas

11

Esta é uma questão muito subjetiva em alguns aspectos, mas vou tentar responder as partes que podem ser razoavelmente respondidas.

O desempenho do MVC não é um pouco lento?

Não. É claro que é possível, através de uma implementação realmente pobre do padrão, causar um mau desempenho (mas isso é verdade de qualquer coisa e de tudo), mas o padrão em si não é inerentemente lento em qualquer consideração. O mapeamento de URLs para métodos de classes de controladores é totalmente trivial e não há razão para não ter um excelente desempenho.

Sim, haverá uma pequena quantidade de sobrecarga, mas também existem diferentes tipos de sobrecarga com aplicativos ASP.NET ou PHP tradicionais. Não pré-otimize . Em vez disso, escolha o framework / tools que faz com que você realize melhor.

A curva de aprendizado também é muito íngreme?

Sua curva de aprendizado é diferente de todas as outras, mas na minha experiência pessoal, foi exatamente o oposto. Com Ruby on Rails e ASP.NET MVC, descobri que o padrão MVC combinava de forma tão óbvia e intuitiva a natureza dos aplicativos da Web que a curva de aprendizado era praticamente inexistente. Pelo contrário, fiquei desapontado comigo mesmo por não ter sido o único a pensar nisso.

    
por 28.04.2011 / 16:32
fonte
4

ASP.NET MVC é o que você chama de "Camada de aplicativo".

Portanto, você ainda deve criar três pastas: camada de aplicativo, camada de negócios e camada de dados, das quais as duas últimas conteriam exatamente o que elas conteriam em outros projetos seus.

A pasta da camada de aplicativos conteria todo o projeto ASP.NET MVC com todas as suas subpastas (models, controllers, content, scripts, ...).

Então, com relação ao desempenho, não acho que isso realmente importe. Você nunca usaria "Roteamento" para invocar um método de camada de negócios ou de camada de dados. Você usa apenas "Roteamento" para invocar métodos do controlador, portanto, para sua interface do usuário (a camada de aplicativo na sua terminologia). Você então invocaria seus métodos de Camada de Negócios de seus controladores, para que isso acontecesse com o mesmo desempenho que outros projetos seus.

    
por 28.04.2011 / 16:32
fonte
3

Camadas e organização sempre têm alguns custos. Se você realmente precisa de desempenho, você deve verificar onde e se vale a pena e em caso afirmativo:

  • comece a remover as camadas
  • quando não houver mais camadas, comece a remover os métodos
  • se não houver métodos, pense em c

No pior de todos os casos, você terá um código de alto desempenho que só poderá ser entendido e com uma portabilidade ou flexibilidade aproximada.

    
por 28.04.2011 / 16:35
fonte