none
View ASP.NET MVC RRS feed

  • Pergunta

  • Srs.,


    usando <%= Html.TextBox("Id", Model.Id) %> não estariamos caindo no mesmo problema dos controles asp.net, ou seja, estamos novamente usando uma forma diferente dos controles nativos html, porque não usar dessa forma <input id="Id" name="Id" type="text" value="<%=Model.Id %>" />.

    está é só uma duvida minha, sempre leio comentários que não temos total controle sobre os controles asp.net para web, usando o exemplo <%= Html.TextBox("Id", Model.Id) %> que Asp.Net MVC teremos esse controle.

    Obrigador a todos.
    segunda-feira, 8 de junho de 2009 13:46

Respostas

  • De certa forma você perde sim um pouco do controle. Isso é inegável.
    Ainda assim, no WebForms isso vai um passo além. No WF você tem a proposta de que o desenvolvedor não precisar saber nada ou quase nada de HTML/CSS/JS. No MVC isso não é assim.
    No WF você tem controles com databinding, controles ricos como calendário, grid, etc. Esses controles escrevem muito mais que um <input>, eles criam grandes cadeias de elementos.
    E por fim, no WF você tem toda uma abstração da manutenção de estado, baseado no viewstate que é implementado com um elemento hidden.
    Ou seja, no MVC estamos realmente um passo além.
    Ainda assim, nada nos impede de usar a forma que você demonstrou, sem o helper. O helper está lá para padronizar, e porque gera um código simples. É para ajudar a automatizar uma tarefa, não é, ou deveria ser, para gerar grids, por exemplo.

    Giovanni Bassi, Microsoft MVP, MCSD, MCPD, CSM, Arquiteto de software - http://www.giovannibassi.com
    quinta-feira, 11 de junho de 2009 03:40
    Moderador

Todas as Respostas

  • Olá Luciano,

    A utilização dos Helpers para montar a view é opcional e você ainda pode criar as suas Helpers conforme a necessidade, ou se preferir pode escrever HTML puro, na verdade os Helpers gera HTML puro, como você mesmo citou acima.


    Se a resposta for útil por favor não esqueça de marca.
    Abraços,
    www.danielfonsecacastro.com.br
    Daniel Fonseca Castro
    terça-feira, 9 de junho de 2009 23:40
  • Daneil,

    obrigado pela atenção, teu site é muito bacana.

    Entendi a opção de usar as duas formas, tando que nos sites que tenho em WebForms procuro usar os controles nativos com a tag runat="server" para facilitar a vida do web design quando monta as páginas no dreamweaver.
    acho que para trablalhar com equipes de desenvolvimento onde as páginas htmls são montadas com outras ferramentas vai dificultar usar os Helpers.

    Abralos,

    Luciano Mattos
    quarta-feira, 10 de junho de 2009 20:41
  • Olá Luciano,

    Pelo que eu entendi você deixava o design montar a pagina e os programadores no code behind.
    Realmente isso terá que mudar para os dois design e programador! Mais as vantagens são tantas que vale muito apena!

    Se você perguntar para qualquer design se ele gostaria de ter o controle do HTML que ele cria , acredito que a resposta será SIM, e para os programadores é só perguntar se ele quer fazer aplicativos testáveis,de fácil manutenção,utilizando boas praticas, etc.... Se o cara responder "não", você tem um problemão!


    Se a resposta for útil por favor não esqueça de marca.
    Abraços,
    www.danielfonsecacastro.com.br
    Daniel Fonseca Castro
    quinta-feira, 11 de junho de 2009 00:21
  • De certa forma você perde sim um pouco do controle. Isso é inegável.
    Ainda assim, no WebForms isso vai um passo além. No WF você tem a proposta de que o desenvolvedor não precisar saber nada ou quase nada de HTML/CSS/JS. No MVC isso não é assim.
    No WF você tem controles com databinding, controles ricos como calendário, grid, etc. Esses controles escrevem muito mais que um <input>, eles criam grandes cadeias de elementos.
    E por fim, no WF você tem toda uma abstração da manutenção de estado, baseado no viewstate que é implementado com um elemento hidden.
    Ou seja, no MVC estamos realmente um passo além.
    Ainda assim, nada nos impede de usar a forma que você demonstrou, sem o helper. O helper está lá para padronizar, e porque gera um código simples. É para ajudar a automatizar uma tarefa, não é, ou deveria ser, para gerar grids, por exemplo.

    Giovanni Bassi, Microsoft MVP, MCSD, MCPD, CSM, Arquiteto de software - http://www.giovannibassi.com
    quinta-feira, 11 de junho de 2009 03:40
    Moderador
  • Luciano,

    também não vejo problemas em utilizar Helpers, pois como o Giovanni disse, eles estão lá para automatizar uma tarefa, e geram um conteúdo bem diferente dos controles dos WebForms.
    Ricardo Oneda Acesse o blog de Ricardo Oneda Acesse o perfil de Ricardo Oneda no Twitter
    sexta-feira, 12 de junho de 2009 12:02
  • Ricaro,

    também não vejo problemas em utilizar Helpers, acho que as vantagens em utilizar os Helpers são muitas, mas para mim que trabalho com uma equipe de desenvolvimento onde os design usam o editor de html da preferencia deles e que cada um trabalha em sua casa ou escritório não vai funcionar.

    Só fiz a pergunta porque tenho essa mesma dificuldade para programar em webforms, integração com o web design.

    Att,

    Luciano Mattos
    sexta-feira, 12 de junho de 2009 12:50
  • só complementando, já pensou eu pegar minha página de cadastro de clientes cheia de helpers e pedir para o web design aplicar o css...
    webforms o dreamweaver ainda reconhece alguns controles mas Helpers....

    sexta-feira, 12 de junho de 2009 12:54
  • Realmente a integração com os designers está sofrendo por causa dos helpers. Você tem a alternativa de trabalhar sem eles, ou pedir que eles trabalhem em um protótipo, que depois o desenvolvedor vai usar para transportar o layout para a view final.
    A coisa piora ainda mais se você usar modelos de view engine que sequer usam html.
    Giovanni Bassi, Microsoft MVP, MCSD, MCPD, CSM, Arquiteto de software - http://www.giovannibassi.com
    sexta-feira, 12 de junho de 2009 14:58
    Moderador