none
.NET MVC Engine de Desenvolvimento de aplicações RRS feed

  • Discussão Geral

  • Prezados amigos,

          Há alguns meses venho estudado e observado a tecnologia .NET MVC (inclusive o preview beta 3) e tenho notado recuros riquissimos na tecnologia, especialmente focada na parte de ORM (Objetos relacionais mapeados) e sua relativa persistência de dados, detalhes como a manipulação da View com recursos JSON e Ajax enriquecem em muito as aplicações. Desenvolvi uma base (engine, core, framework, como queiram chamar) para absover, abstrair e otimizar o desenvolvimento em equipe de aplicações, no contexto DAL (Data Acess Layer), BLL e manipulação e interatividade com JSON a engine ficou muito satisfatoria.  

         Venho estudando projetos idealizados pela comunidade como o MVCControlToolKit, Controlib, # Architeture e demais samples disponibilizados para aderir idéias e outras informações uteis que possa agregar a engine desenvolvida, noto que, com o MVC perdeu-se o poder (ou parte dele) de controlar objetos ricos em interface de maneira generica... ou seja... não tem-se mais o poder (facilidade) de um ajaxcontroltoolkit ou similares... (me corrijam caso esteja errado) sem necessáriamente ter que codificar (trabalho bracal) muito e otimizar bibliotecas jQUery para alcançar tal similariedade. Sei que, maneiras de fazer se tem aos montes, eficiencia e total poder do html é dados para enfatizar e abstrair tudo que se queira fazer, o foco que tento expor aqui é: uma facilidade de trabalhar com objetos ricos em interatividade de maneira mais generica no .NET MVC.... como tal se tinha (com alguns detrimentos) nos WebForms, gostaria de propor uma discurssão sadia que objetive idéias para as repercussões citadas acima, informações utéis de manipulação de objetos na View, idéias para projetos que manipulam n tipos de objetos genericos, dicas de usabilidades e boas práticas em padrões MVC, tudo que possa agregar valor.

     

    Obrigado pela atenção

    Gustavo Henrique

     

     

    • Editado GUSTAVOGHDD sexta-feira, 14 de janeiro de 2011 15:45 Correção de palavras
    sexta-feira, 14 de janeiro de 2011 00:54

Todas as Respostas

  • Gustavo,

    Eu particularmente adorei o MVC. 

    Depois de trabalhar com WebForms algum tempo, eu tive algumas experiências que não foram muito sadias. Vou citar algumas delas:

    1) ViewState: O peso das páginas é péssimo e o consumo de banda é altíssimo. ViewState existe somente para que o servidor consiga "reconstruir" o estado da página no lado do servidor para você manipular esses valores e todo o processo de re-geração de HTML/Javascript aconteça novamente.

    2) Postback: A estrutura de postbacks criada também no modelo ASP.Net WebForms gera alguns efeitos colaterais terríveis. Por exemplo, tente gerar uma página ASP.Net e via AJAX tradicional (JQuery, XMLHttpRequest e outros) colocar uma página dentro de um DIV. O ViewState corrompe no próximo postback.

    3) AjaxControlToolkit: O UpdatePanel existe praticamente por causa do ponto "2" acima. Isso forçou a Microsoft a criar meio que o AJAX dela. Por isso existe AjaxControlToolkit. Eles tentaram pegar uma série de idéias que se resolvem via requests HTTP assíncronos e consolidar em web controls. Esses web controls são completamente bugados. Até o UpdatePanel tem seus problemas para funcionar em vários browsers. Eu perco mais tempo lutando contra eles do que escrevendo código Javascript que funciona. Você ganha o AjaxControlToolkit, e perde tudo o que já foi feito em javascript por várias outras iniciativas de java, php e tantas outras linguagens Web que já existem até a mais tempo que o ASP.Net.

    4) Alto consumo de CPU. O trabalho que o Web Server faz de parsear o DOM da páginas e jogar para as classes, instanciar e matar os objetos no server side a cada request/postback é um baita overhead de CPU. Quando você começa a mexer com MVC, você sente a diferença na hora. No caso do AJAX é pior ainda. Mesmo que você trafegue somente um pedaço da página e diminua o consumo de banda, a página está sendo processada quase que inteira do lado do servidor para cada request assíncrono, fazendo esse trabalho de montar/desmontar a árvore, para que possa ser possível saber qual pedaço da árvore precisa ser devolvida pelo servidor.

    5) Controles dinâmicos. Meu blog teve 10.000 acessos em 2010. Um dos artigos mais acessados foi este:  http://ericlemes.com/2009/01/12/dotnet-controlesdinamicos/

    A moral da história é que uma tarefa tão simples quanto criar controles em tempo de execução precisa que você entenda quase toda a estrutura do ASP.Net WebForms para ser feita. Todas as vezes que eu tivesse esse tipo de problema (Ex.: Montar campos numa página baseado em informações do banco de dados, ou metadados), eu passei bastante raiva.

     

    Em resumo, eu citei tudo isso porque o MVC resolve TODOS os problemas citados acima e gera um único inconveniente. As pessoas precisam passar a programar na Web sabendo como a Web funciona. Para muitos desenvolvedores isso é um inconveniente. Para mim não.

    Muitos desenvolvedores amam o ASP.Net WebForms porque conseguem fazer algo sem saber programar em javascript ou mesmo conhecer HTML a fundo. O resultado disso são aplicações pobres, lentas, que em geral só funcionam no Internet Explorer.

    O ASP.Net MVC faz com que o desenvolvedor tenha que saber HTML e Javascript, coisa que qualquer desenvolvedor Web deveria saber.

    Se o objetivo for desenvolver mais fácil, continue no Web Forms. Se o objetivo for construir aplicações melhores e mais rápidas, sem dúvida o MVC é caminho sem volta.

     

    Abraço,

    Eric

    sexta-feira, 14 de janeiro de 2011 10:34
  • Eu ia até escrever algo, mas não tinha lido o post do Eric, muito bem escrito e argumentado.

    Concordo 100% com o Eric.


    Contato:albertim_brasil@hotmail.com - Se ajudei, marca como útil.
    Twitter: Me siga!!
    Blog:http://dotnettime.wordpress.com/

    sexta-feira, 14 de janeiro de 2011 12:27
  • Ola Eric, tudo de bom!?

     

    Grato pelas colocações, muito do apresentado já tenho como base para distinção entre as tecnologias WebForms x MVC. Citei inclusive alguns ganhos de um em relação ao outro, etc. Partindo do princípios que o MVC forçe um desenvolvimento mais pesado por parte do analista para desenvolvimento de componentes/controles/implementações assincronas, pelo observado pelo seu post, ha de concorda que os WebForms garantem uma facilidade nesse item (mesmo tendo varios impecilios conforme o mencionado).

     

    Como citei no post que deu abertura a esse topico, tenho tentado desenvolver uma maneira de facilitar o desenvolvimento em MVC como se fosse um WebForms (claro que nao igual) no contexto de controles genéricos, mais inteligentes e ageis, como se o proprio desenvolvedor tivesse digitado todo o codigo rico em ajax ou json, porem, de forma automatizada. Tenho alguns exemplos implementados que deram certo, estava(ou) pensando em até disponibilizar o fonte criado/em desenvolvimento para que a comunidade possa utilizar e contribuir com melhorias (mas algumas questões legais ainda tem que ser observadas). Um objetivo que tenho nas argumentações é em construir referencias/idéias que contribuam nesse processo, como falado anteriormente, venho estudado muitos exemplos e fontes para uma melhor concepção do conceito do framework criado em cima do MVC, nas camadas de persistência e Negócio estão muito satisfatorios, o enfoque agora é a automação da criação de componentes e controles ricos, bibliotecas customizadas apoiadas no jquery estão sendo adotadas também, que forçem menos (nao quer dizer que nao force, ou que o analista nao teria capacidade de fazer, nao é isso o ponto) a interação com a interface com o usuário.

     

    Continuemos...

     

    Agradeço a todos pela participação.

     

    Gustavo Henrique

    • Editado GUSTAVOGHDD sexta-feira, 14 de janeiro de 2011 14:20 formatação do texto
    sexta-feira, 14 de janeiro de 2011 14:17
  • Gustavo,

    É essa linha mesmo. Acredito que você esteja indo no caminho certo.

    A idéia é construir alguns javascripts de controles mais ricos visualmente no HTML, mesmo pegar implementações já criadas por outras pessoas para uma UI mais rica na Web e acoplar no MVC. O principal recurso para isso acredito que sejam os HTML Renderers.

    Se vc criar bons renderers para encapsular a complexidade do HTML e javascript, consegue uma produtividade igual ou superior ao Web Forms.

    Eu acho que a comunidade do MVC vai seguir neste caminho daqui uns 2-3 anos vamos ter excelentes renderers prontos. No WebForms a coisa tá mais pronta pq começou antes, mas acho que esta tecnologia tenha restrições que a inviabilizam em cenários de alta performance e aplicações de alta escalabilidade.

     

    Por favor, se as respostas são úteis, marque como resposta.

     

    Abraço,

    Eric

    sexta-feira, 14 de janeiro de 2011 15:25
  • Concordo plenamente com o Eric.
    MiTz
    sexta-feira, 14 de janeiro de 2011 17:32
  • Concordo tbm com o Eric.

     

    ;)

    quarta-feira, 19 de janeiro de 2011 17:14