none
Utilizar ou não MVC para obter melhor Performance e Escabilidade RRS feed

  • Pergunta

  • Olá Pessoal,

     

    Tenho um cliente que possue um E-Commerce com as seguintes funcionalidades: 

    devo utilizar MVC para este caso?

     

    -Vitrine

    -Listagem de produto por categorias

    -Detalhe de Produto

    -Visualização do Carrinho

    -Login no Carrinho

    -Confirmação da Compra

    -Conclusao do Pedido

    -Listagem dos dados do cliente

    -Listagem dos Pedidos do Cliente

    -Detalhe do pedido do cliente

    sexta-feira, 13 de agosto de 2010 12:59

Todas as Respostas

  • Olá Matheus,

    Eu utilizaria o ASP.NET MVC pois com ele a testabilidade é simples, e sua aplicação será mais escalável e extensivel, mas consequentemente você gastará um pouco mais de tempo modelando sua aplicação (leve isso em conta se seu prazo é curto).

    Vai algumas dicas para manter um projeto simples, facil de manter e extender com o ASP.NET MVC:

     - Manter 3 projetos, um para sua aplicação Web MVC, outro para seus TESTES unitários e mais um projeto para o Domínio(projeto class library) de sua aplicação (onde ficará suas entidades, serviços, regras de negocio e etc).

     - Utilizar um Containner de Injeção de Dependência para injetar as dependências para você (ex. Ninject)

     - Tente utilizar os principios S.O.L.I.D. (ref. http://viniciusquaiato.com/blog/tag/solid/)

     - Utilize conceitos de Domain Driven Design, caso não conheça sugiro a leitura de alguns blogs da comunidade, que possuem posts sobre o assunto (ref. http://unplugged.giggio.net/unplugged/post/Video-sobre-Domain-Driven-Design.aspx). 

     

    domingo, 15 de agosto de 2010 15:16
  • Fala Matheus,

    Além das dicas do William, vale salientar que você deve levar em consideração a curva de aprendizagem do próprio ASP.NET MVC do seu time, principalmente se o time tem muita experiência com Web Forms. Se for esse o caso, em um primeiro momento vocês certamente experimentarão uma menor produtividade.

    Leve isso em conta e envolva o cliente nessa decisão. De qualquer forma, também recomendo fortemente a utilização do ASP.NET MVC... ;)

     


    Forte abraço,

    André Borges Medeiros
    MCT, MCPD, MCTS

    >> Se a resposta solucionar sua dúvida, favor Votar como Útil
    segunda-feira, 16 de agosto de 2010 12:31
    Moderador
  • As dicas dos colegas são excelentes então focarei nas questões performance e escalabilidade.

    No caso da performance existem muitas variáveis, mas eu separaria a performance em duas categorias para discutir rapidamente aqui: a performance da resposta da interface com o usuário e a performance dos processos das regras de negócio.

    Para resposta rápida ao usuário é excelente o MVC porque lhe deixa livre para usar qualquer tecnologia como view, não lhe deixa preso a um framework como o Web Forms o faz. Desde o simples HTML + CSS que causa um excelente efeito com o trabalho de um bom designer até interfaces sofisticadas usando bibliotecas javascript como ExtJS e JQuery usando Ajax o que irá deixar sua interface com o usuário fluir muito melhor, com feedback rápido para o usuário, quase como no desktop. Aqui também é importante tratar as informações que são enviadas ao browser, um alto volume de dados pode atrapalhar, e muito, a performance. Também vale não deixar o usuário executar filtros muito abrangentes, que retornem muitos registros, tentar sempre filtrar ou usar paginação dos dados. Um usuário geralmente precisa somente de poucos registros para trabalhar.

    Para a performance das regras de negócio é preciso avaliar um pouco mais a fundo a necessidade de sua aplicação. Ela irá atender quantos usuários simultâneos ? Dependendo da quantidade de acessos simultâneos você pode criar um gargalo nos processos de negócio. As exceções precisam ser tratadas de forma adequada porque isso pode causar redução de produtividade ao usuário da sua aplicação o que, para nossos clientes, pode ser chamado de lentidão no sistema porque o usuário não conseguirá concluir suas tarefas a tempo... (a culpa é sempre "do sistema") Também tome cuidado com processos demorados. A maioria desses processos não precisam bloquear o uso do sistema pelo usuário, tente usar threads ou filas (MSMQ, por exemplo). Usar paralelismo nas regras de negócio também é uma boa. Imagine que na sua listagem de dados do cliente você tenha que processar milhões de registros caso o usuário use um filtro muito abrangente, usar o paralelismo do LINQ, o PLINQ, é recomendado.

    Ah! Os padrões, use os padrões que puderem ser aplicados (use bom senso também), tanto os padrões OO (http://www.artmed.com.br/WEB-PRODUTOS/produto_detalhe.aspx?id_produto=1016) como os padrões para aplicações corporativas do Martin Fowler (http://www.artmed.com.br/WEB-PRODUTOS/produto_detalhe.aspx?id_produto=1973)

    E a escalabilidade? Bem, seguir as dicas dos colegas de separar logicamente a aplicação é a primeria coisa a se fazer. Geralmente separo as aplicações, logicamente, da seguinte forma: Apresentação (UI), Serviços (Façades, Webservices, WCF services), Regras de negócio (Serviços específicos como um CRUD ou uma pesquisa no SERASA, por exemplo), Modelo (Entidades de negócio) e Dados (ou Persistência). Cada um é um projeto de biblioteca de classes separado, com exceção dos projetos que exigem interação visual com o usuário. A camada de serviços no meu caso é um agregador de serviços específicos (um façade de clientes, por exemplo, pode usar o serviço específico do cliente para pesquisar dados dele e pode também utilizar o serviço de consultas ao SERASA, sacou?). Aqui entra a injeção de dependência já sugerida, aqui também é muito melhor que você trabalhe exclusivamente com interfaces (geralmente somente os objetos do modelo não são baseados em interface), com isso você ganha uma alta coesão e um nível baixíssimo de acoplamento o que nos leva, finalmente, à escalabilidade possível.

    Que tipos de scalabilidade? Bom, a primeira que se consegue é escalabilidade no front-end. Com essa arquitetura você pode utilizar basicamente três servidores: Um para a interface (o IIS), um servidor de aplicações (façades e serviços específicos) e um servidor de banco de dados.

    No front-end é possível criar um farm de servidores para responder às requisições dos usuários, basicamente você aumenta a quantidade de servidores conforme a necessecidade e isso é transparente para os usuários. O mesmo acontece para o servidor de aplicação, você pode balancear a carga de processamento das requisições que chegam pelo front-end e, por fim, pode ser usado um cluster de bancos de dados ou um banco de dados distribuído, novamente possibilitando um balanceamento de carga no acesso aos dados.

    Com farms e cluster você tanto ganha escalabilidade como ganha em performance, mas o caso da performance em 90% das vezes é solucionado na aplicação sem aumentar hardware ou realizar configurações malucas.

    Ainda sobre escalabilidade: Lembra-se do uso de interfaces e injeção de dependência? Pois bem, imagine que seu serviço de análise de crédito do cliente a partir de agora não consulta somente o SERASA, irá consultar um outro serviço qualquer de análise de risco, basta criar o tal serviço e injetá-lo no processo atual, nada do restante da aplicação precisará ser alterado. Ou, ainda, o cliente começou com um banco de dados como o PostgreSQL por um motivo qualquer e, agora que o produto é um sucesso, precisa da robustez de um SQL Server ? Bem, sua camada de dados também é baseada em interfaces e está sendo injetada, substitua-a pela nova camada que acessa o SQL Server usando o Entity Framework e pronto, sua aplicação continua funcionando. Óbviamente algumas alterações não são tão simples assim, mas acredito você entendeu a idéia.

    Bem, é isso, espero que ajude.

    quarta-feira, 18 de agosto de 2010 02:56
  • Matheus,

    eu tive a oportunidade de trabalhar com os dois projetos tanto web.forms quando asp.net MVC. Trabalhei primeito com Web.Forms para depois trabalhar com MVC.

    Tudo que o pessoal fala sobre limpeza do código HTML é realmente bancana, ele realmente limpa o código. Quando a escalabilidade e performance sinceramente não vi muita diferença não.

    Agora quando ao conceito do MVC que separa as classes de negócio e apresentação com o modelo isso realmente é bacana e tem ser aplicado nos dois casos. Eu até gosto de incrementar o MVC com o DAL que é separar a camada de dados também é interessante e é um padrão. Como o Flávio mencionou separa tudo em 4 projetos, um para interface, modelo (represetação orientada da sua base), Regra e DAL ou CAD(Camada de acesso a dados).

    Quando a utilização de template de projeto ASP.NET MVC eu não vi grandes dificuldades em trabalhar com ele apesar de ter achado muito mais trabalhoso que o Web.forms. Nele a liberdade de componentes é muito boa porque temos os componentes do jQuery a disposição, mas por experiência nem todos são somente pegar e utilizar.

    Uma coisa que pondero bastante é que construir uma página com 3 dropdownlist em castaca e um grid view tive que escrever mais ou menos 100 linhas de js, enguanto no web forms era só utlizar três componentes.

    Mas eu gosto dessa velocidade de construção de tela no web forms, me ocupa menos tempo em como que vou fazer os componente da tele e mais tempo com o que relamente a aplicação faz. Prete atenção que se preocupar menos tempo com tela não é falar que vou ter uma tele mais ou menos bonita e nem mais ou menos funcional para o usuário porque tudo que você faz em questão de design e usabilidade em um você tambem faz para o outro.

     

    Não defendo nenhum nem outro, escolha o que for melhor para o seu projeto e siga em frente porque nos dois caminhos vão existir pedras, e infelizmente não tem como saber se todas as pedras do caminho 1 vão ser maiores o menores do que no caminho 2 então..

    Se estiver contando pontos por opnião e minha é utilize o web form e construa uma arquitetura boa, con certeza vai ter uma boa aplicação. Isso também não é possível utilizando ASP.NET MVC? Claro que é! Eu só acho mais fácil construir em web forms :D

     

    Espero ter mais ajudado do que atrapalhado.

    domingo, 26 de setembro de 2010 03:57