.NET é lento?
Participantes: Fabio Camara, Mauro SantAnna, Rodolpho Sá, Fabio Gouw, Luiz Thadeu, Cleiton Sacramento, Sérgio Iwasaki, Daniel Gilbertoni, Bruno Frigeri, Miguel Luiz, Bruno Morozini, Daniel Chinen, Douglas Zancheta e João Scarano.
Assuntos Abordados
Discussão: .NET é lento?
Conclusões:
- Cuidado com a comparação, como por exemplo com o Clipper;
- Quando em necessidade de dividir o processamento devemos utilizar o banco de dados com stored procedures;
- É gritante a diferença entre providers oledb e sqldb;
- Nada é mais rápido que um ISAM mono-usuário;
- Os bancos de dados SGBD são usados por questões de segurança e integridade, e não por performance – Clipper / DBF é mais rápido;
- É mais rápido que o Java;
- É praticamente igual ao Delphi e Visual Basic 6.0;
- Tem questões de memória e questões de arquitetura que influem;
- Em situação de pouca memória (32 mb ou 64 mb) o .NET será mais lento.
Discussão: Escrever código em .NET é mais demorado?
Conclusões:
- Para Winforms os componentes é que fazem a diferença;
- Incondicionalmente não, pode ser uma sensação causada pelo aprendizado de uma nova linguagem, bibliotecas e ferramentas;
- O Framework e o modelo de programação fazem diferença.
Discussão: É improdutivo desenvolver com arquitetura 4 camadas?
Conclusões:
- O Data Access Framework não atende completamente (50% em média);
- Existem questões muito específicas de READ e WRITE para componentes de acesso a dados;
- Colocar tudo na camada de apresentação é mais rápido de desenvolver mesmo, contudo:
- A manutenção será horrível;
- Não permite reusabilidade;
- Isolar em camadas é uma pratica recomendada até academicamente.
- Para questões conceituais sobre usar ou não usar stored procedures não existem respostas genéricas;
- O esquema do Data Access Framework é extremamente acadêmico, a diferença é a questão de Value Types (diferença entre diagrama de classe versus dataset tipado);
- O READ deve ser usado basicamente para grids e relatórios.
