Seguinte.. já trabalho com programação tem uns 10 anos... antes disso brincava de "programar" HTML na época em que o Jornal do Brasil era o primeiro jornal na internet e as pessoas faziam coleção de CDs da AOL.
Há um bom tempo. Bom mesmo, não preciso programar interfaces com o usuário fico responsável por fazer as camadas internas ou montando serviços para serem consumidos, etc...
De um ano pra cá, fiquei mais próximo da interface, mas mesmo assim não tive que meter a mão na massa. Mas hj estou em um projeto em que estou usando webform tradicional com MS.AJAX e não estou tendo problemas, como é um sistema de uso interno e na demanda de alta performance de UI e nem telas escalafobéticas... Achei uma opção interessante...
Mas pq estou falando tudo isso??? Bem, nos primórdios de minha vida profissional onde comecei com DELPHI e depois fiquei um tempo com o CENTURA (SQLWindows) fui apresentado ao ASP e o seu VB Script.
Apesar de tudo (VB Script), descobri que gostava de programar pra WEB e fiz grandes sistemas em ASP. Inclusive um CMS Multilíngüe que acaba de completar 8 anos de produção sem cair que atende muito bem o propósito para que foi feito.
Me lembro que os maiores problemas daquela época era a respeito de como tratar a UI... e como dava trabalho programar javascript que funcionasse em todos os browsers e resoluções, manter o estado entre páginas, etc....
Aí surgiu o ASP.NET 1.0 e como em um comercial das organizações Tabajara esta tecnologia veio para resolver todos os nossos problemas técnicos... aos poucos migrei para o .NET e fiz outros tantos sistemas. Alguns um grande sucesso outros e outros apenas sistemas....
Continuei o meu caminho e cada vez mais me afastei da UI... Então esse ano em um grande projeto, a decisão do arquiteto foi usar o ASP.NET MVC e por sorte minha não fiquei responsável pela UI... E vi como um amigo sofreu pra (ele não programou pra "WEB 1.0") garantir Javascript em todos os browsers (ele usou jquery). E uma coisa que não via a anos, ele programou no HTML mesmo não sendo negócio.
Aí pensei.... estamos voltando ao início de tudo?
Mas como não tinha "mexer" com o problema e tinha outras partes do sistema pra construir não me preocupei com isso...
Mas agora estou em um projeto em que preciso decidir entre o tradicional e o novo (velho).
Que opções tenho pra um webforms mais "digno" sem usar o ASP.NET MVC? Ou pq o ASP.NET MVC é tão bom? Pq me dá o HTML na mão? Isso é bom realmente? ou os que estão usando não o tiveram na mão no passado para que pudesse comparar com o presente?
Por favor não me crucifiquem, não sou o anti-cristo. Só quero entender o pq algo que tínhamos no passado e que as pessoas e o mercado festejaram quando tiveram a possibilidade se livrar deste controle, agora é a solução para todas as nossos problemas técnicos. agora é a melhor opção para construir um sistema novo.
Não estou discutindo o que está por dentro, quero lidar especificamente com a UI. até pq mesmo no ASP tinha uma boa separação de camadas...
Eu que nunca gostei de web mais to gostando bastante de MVC entendo bastante suas ponderações.... Como eu postei recentemente em meu blog http://sourcerule.wordpress.com/, (acesse e comente, voce vai gostar) tecnologias vão e vem e este negócio de tudo ser a 8 maravilha é foda.... Tenho certeza que o ASP MVC irá evoluir pra algo parecido com o arrastar e soltar novamente. É só uma questão de tempo. O que não da pra engolir são os argumentos dos evangelistas donos da verdade sobre este suposto atrazo nesta parte de ui do MVC: "Só pessoas que não são qualificadas o suficiente que vão reclamar....". Seus 10 anos de experiencia já prova o contrario. Mais ta bom, alguem tem que estar sempre vendendo.
Não sou anti-MVC, tenho certeza que o ASP.net tradicional vai acabar morrendo pra ele, mais ele ainda precisa evoluir muito principalmente no que diz respeito a produtividade.
> Seguinte.. já trabalho com programação tem uns 10 anos... antes disso > brincava de "programar" HTML na época em que o Jornal do Brasil era o > primeiro jornal na internet e as pessoas faziam coleção de CDs da AOL.
> Há um bom tempo. Bom mesmo, não preciso programar interfaces com o > usuário fico responsável por fazer as camadas internas ou montando serviços > para serem consumidos, etc...
> De um ano pra cá, fiquei mais próximo da interface, mas mesmo assim não > tive que meter a mão na massa. Mas hj estou em um projeto em que estou > usando webform tradicional com MS.AJAX e não estou tendo problemas, como é > um sistema de uso interno e na demanda de alta performance de UI e nem telas > escalafobéticas... Achei uma opção interessante...
> Mas pq estou falando tudo isso??? Bem, nos primórdios de minha vida > profissional onde comecei com DELPHI e depois fiquei um tempo com o CENTURA > (SQLWindows) fui apresentado ao ASP e o seu VB Script.
> Apesar de tudo (VB Script), descobri que gostava de programar pra WEB e > fiz grandes sistemas em ASP. Inclusive um CMS Multilíngüe que acaba de > completar 8 anos de produção sem cair que atende muito bem o propósito para > que foi feito.
> Me lembro que os maiores problemas daquela época era a respeito de como > tratar a UI... e como dava trabalho programar javascript que funcionasse em > todos os browsers e resoluções, manter o estado entre páginas, etc....
> Aí surgiu o ASP.NET 1.0 e como em um comercial das organizações Tabajara > esta tecnologia veio para resolver todos os nossos problemas técnicos... aos > poucos migrei para o .NET e fiz outros tantos sistemas. Alguns um grande > sucesso outros e outros apenas sistemas....
> Continuei o meu caminho e cada vez mais me afastei da UI... Então esse > ano em um grande projeto, a decisão do arquiteto foi usar o ASP.NET MVC e > por sorte minha não fiquei responsável pela UI... E vi como um amigo sofreu > pra (ele não programou pra "WEB 1.0") garantir Javascript em todos os > browsers (ele usou jquery). E uma coisa que não via a anos, ele programou no > HTML mesmo não sendo negócio.
> Aí pensei.... estamos voltando ao início de tudo?
> Mas como não tinha "mexer" com o problema e tinha outras partes do > sistema pra construir não me preocupei com isso...
> Mas agora estou em um projeto em que preciso decidir entre o tradicional > e o novo (velho).
> Que opções tenho pra um webforms mais "digno" sem usar o ASP.NET MVC? Ou > pq o ASP.NET MVC é tão bom? Pq me dá o HTML na mão? Isso é bom realmente? > ou os que estão usando não o tiveram na mão no passado para que pudesse > comparar com o presente?
> Por favor não me crucifiquem, não sou o anti-cristo. Só quero entender o > pq algo que tínhamos no passado e que as pessoas e o mercado festejaram > quando tiveram a possibilidade se livrar deste controle, agora é a solução > para todas as nossos problemas técnicos. agora é a melhor opção para > construir um sistema novo.
> Não estou discutindo o que está por dentro, quero lidar especificamente > com a UI. até pq mesmo no ASP tinha uma boa separação de camadas...
> -- > Você recebeu esta mensagem porque faz parte do grupo .Net Architects > hospedado no Google Groups. > Para postar envie uma mensagem para dotnetarchitects@googlegroups.com > Para sair do grupo envie uma mensagem para > dotnetarchitects+unsubscribe@googlegroups.com<dotnetarchitects%2Bunsubscrib e@googlegroups.com> > Para mais opções visite o grupo em > http://groups.google.com/group/dotnetarchitects?hl=pt-br
Eu também estou envolvido com programação há mais de 10 anos e, assim como você, sempre preferi trabalhar com o back-end da aplicação, em vez de ficar às voltas com UI. Entretanto, não tem como guiar equipes sem conhecer as tecnologias nas quais elas trabalham a fundo. Trabalhei com WebForms intensivamente por 6 meses. Foi o suficiente para odiá-lo do fundo do meu coração. Posso estar sendo extremista, mas qualquer pessoa que se importe com a elegância de um código se incomoda com o a desorganização que ficam as páginas ASPX. Ainda mais vendo o HTML que elas geram.
WebForms só é fácil se você confia 100% no Visual Studio. E mesmo assim ele te amarra de uma forma inacreditável.
O ASP.NET MVC ainda está meio verde, mas ele se propõe a se parecer com o ActionPack do Rails. Se você não conhece, recomendo que estude sobre ele. A idela é genial.
Todo mundo aqui na empresa teve um momento de dizer o mesmo que você: "por que eu vou abandonar tudo o que o WebForms me trouxe (controles, patterns, etc.) para trabalhar com HTML?". Eu nunca consegui convencer ninguém sem mostrar código. Por isso realizamos diversos Coding Dojos aqui na empresa para mostrar como e porque o ASP.NET MVC came to kick WebForms' ass out. É simplesmente fantástico.
Entretanto, o único conselho que eu dou pra qualquer pessoa que entre no ASP.NET MVC é o mesmo que dou para quem aprende Rails ou Karate: entenda o porquê das coisas antes de criticá-las. Talvez uma solução não lhe pareça a mais elegante a princípio (como a questão de CoC com os ModelBinders), mas talvez exista um motivo para ela estar lá.
Em linhas gerais, e com um argumento extremamente falacioso, eu digo que ASP.NET MVC rocks porque ele me fez gostar de desenvolver interfaces. Talvez você também se sinta assim, se pesquisar mais.
> Seguinte.. já trabalho com programação tem uns 10 anos... antes disso > brincava de "programar" HTML na época em que o Jornal do Brasil era o > primeiro jornal na internet e as pessoas faziam coleção de CDs da AOL.
> Há um bom tempo. Bom mesmo, não preciso programar interfaces com o > usuário fico responsável por fazer as camadas internas ou montando serviços > para serem consumidos, etc...
> De um ano pra cá, fiquei mais próximo da interface, mas mesmo assim não > tive que meter a mão na massa. Mas hj estou em um projeto em que estou > usando webform tradicional com MS.AJAX e não estou tendo problemas, como é > um sistema de uso interno e na demanda de alta performance de UI e nem telas > escalafobéticas... Achei uma opção interessante...
> Mas pq estou falando tudo isso??? Bem, nos primórdios de minha vida > profissional onde comecei com DELPHI e depois fiquei um tempo com o CENTURA > (SQLWindows) fui apresentado ao ASP e o seu VB Script.
> Apesar de tudo (VB Script), descobri que gostava de programar pra WEB e > fiz grandes sistemas em ASP. Inclusive um CMS Multilíngüe que acaba de > completar 8 anos de produção sem cair que atende muito bem o propósito para > que foi feito.
> Me lembro que os maiores problemas daquela época era a respeito de como > tratar a UI... e como dava trabalho programar javascript que funcionasse em > todos os browsers e resoluções, manter o estado entre páginas, etc....
> Aí surgiu o ASP.NET 1.0 e como em um comercial das organizações Tabajara > esta tecnologia veio para resolver todos os nossos problemas técnicos... aos > poucos migrei para o .NET e fiz outros tantos sistemas. Alguns um grande > sucesso outros e outros apenas sistemas....
> Continuei o meu caminho e cada vez mais me afastei da UI... Então esse > ano em um grande projeto, a decisão do arquiteto foi usar o ASP.NET MVC e > por sorte minha não fiquei responsável pela UI... E vi como um amigo sofreu > pra (ele não programou pra "WEB 1.0") garantir Javascript em todos os > browsers (ele usou jquery). E uma coisa que não via a anos, ele programou no > HTML mesmo não sendo negócio.
> Aí pensei.... estamos voltando ao início de tudo?
> Mas como não tinha "mexer" com o problema e tinha outras partes do > sistema pra construir não me preocupei com isso...
> Mas agora estou em um projeto em que preciso decidir entre o tradicional > e o novo (velho).
> Que opções tenho pra um webforms mais "digno" sem usar o ASP.NET MVC? Ou > pq o ASP.NET MVC é tão bom? Pq me dá o HTML na mão? Isso é bom realmente? > ou os que estão usando não o tiveram na mão no passado para que pudesse > comparar com o presente?
> Por favor não me crucifiquem, não sou o anti-cristo. Só quero entender o > pq algo que tínhamos no passado e que as pessoas e o mercado festejaram > quando tiveram a possibilidade se livrar deste controle, agora é a solução > para todas as nossos problemas técnicos. agora é a melhor opção para > construir um sistema novo.
> Não estou discutindo o que está por dentro, quero lidar especificamente > com a UI. até pq mesmo no ASP tinha uma boa separação de camadas...
> -- > Você recebeu esta mensagem porque faz parte do grupo .Net Architects > hospedado no Google Groups. > Para postar envie uma mensagem para dotnetarchitects@googlegroups.com > Para sair do grupo envie uma mensagem para > dotnetarchitects+unsubscribe@googlegroups.com<dotnetarchitects%2Bunsubscrib e@googlegroups.com> > Para mais opções visite o grupo em > http://groups.google.com/group/dotnetarchitects?hl=pt-br
É possível programar webform de forma elegante, inclusive W3C. Conheço exemplos práticos...
Existe motivo pra tudo na vida, até pra matar... Então, existe motivo pra ter o ViewState(mas posso retirar se eu quiser) e os nomes complexos e javascript, tb é possível fazer de forma mais amigável.
Acho que na vida, toda escolha é uma renúncia, Se optar por webform estou renunciando algo e se optar por MVC, tb estou renunciando...
Só quero entender pq MVC é a bala que matou Kennedy?
On 25 jan, 12:18, "Juan Pedro A. Lopes" <zerova...@gmail.com> wrote:
> Eu também estou envolvido com programação há mais de 10 anos e, assim como > você, sempre preferi trabalhar com o back-end da aplicação, em vez de ficar > às voltas com UI. Entretanto, não tem como guiar equipes sem conhecer as > tecnologias nas quais elas trabalham a fundo. Trabalhei com WebForms > intensivamente por 6 meses. Foi o suficiente para odiá-lo do fundo do meu > coração. Posso estar sendo extremista, mas qualquer pessoa que se importe > com a elegância de um código se incomoda com o a desorganização que ficam as > páginas ASPX. Ainda mais vendo o HTML que elas geram.
> WebForms só é fácil se você confia 100% no Visual Studio. E mesmo assim ele > te amarra de uma forma inacreditável.
> O ASP.NET MVC ainda está meio verde, mas ele se propõe a se parecer com o > ActionPack do Rails. Se você não conhece, recomendo que estude sobre ele. A > idela é genial.
> Todo mundo aqui na empresa teve um momento de dizer o mesmo que você: "por > que eu vou abandonar tudo o que o WebForms me trouxe (controles, patterns, > etc.) para trabalhar com HTML?". Eu nunca consegui convencer ninguém sem > mostrar código. Por isso realizamos diversos Coding Dojos aqui na empresa > para mostrar como e porque o ASP.NET MVC came to kick WebForms' ass out. É > simplesmente fantástico.
> Entretanto, o único conselho que eu dou pra qualquer pessoa que entre no > ASP.NET MVC é o mesmo que dou para quem aprende Rails ou Karate: entenda o > porquê das coisas antes de criticá-las. Talvez uma solução não lhe pareça a > mais elegante a princípio (como a questão de CoC com os ModelBinders), mas > talvez exista um motivo para ela estar lá.
> Em linhas gerais, e com um argumento extremamente falacioso, eu digo que > ASP.NET MVC rocks porque ele me fez gostar de desenvolver interfaces. Talvez > você também se sinta assim, se pesquisar mais.
> 2010/1/25 Henrique Jacob <analista....@gmail.com>
> > Olá!
> > Não sei se é off, mas vms lá!
> > Seguinte.. já trabalho com programação tem uns 10 anos... antes disso > > brincava de "programar" HTML na época em que o Jornal do Brasil era o > > primeiro jornal na internet e as pessoas faziam coleção de CDs da AOL.
> > Há um bom tempo. Bom mesmo, não preciso programar interfaces com o > > usuário fico responsável por fazer as camadas internas ou montando serviços > > para serem consumidos, etc...
> > De um ano pra cá, fiquei mais próximo da interface, mas mesmo assim não > > tive que meter a mão na massa. Mas hj estou em um projeto em que estou > > usando webform tradicional com MS.AJAX e não estou tendo problemas, como é > > um sistema de uso interno e na demanda de alta performance de UI e nem telas > > escalafobéticas... Achei uma opção interessante...
> > Mas pq estou falando tudo isso??? Bem, nos primórdios de minha vida > > profissional onde comecei com DELPHI e depois fiquei um tempo com o CENTURA > > (SQLWindows) fui apresentado ao ASP e o seu VB Script.
> > Apesar de tudo (VB Script), descobri que gostava de programar pra WEB e > > fiz grandes sistemas em ASP. Inclusive um CMS Multilíngüe que acaba de > > completar 8 anos de produção sem cair que atende muito bem o propósito para > > que foi feito.
> > Me lembro que os maiores problemas daquela época era a respeito de como > > tratar a UI... e como dava trabalho programar javascript que funcionasse em > > todos os browsers e resoluções, manter o estado entre páginas, etc....
> > Aí surgiu o ASP.NET 1.0 e como em um comercial das organizações Tabajara > > esta tecnologia veio para resolver todos os nossos problemas técnicos... aos > > poucos migrei para o .NET e fiz outros tantos sistemas. Alguns um grande > > sucesso outros e outros apenas sistemas....
> > Continuei o meu caminho e cada vez mais me afastei da UI... Então esse > > ano em um grande projeto, a decisão do arquiteto foi usar o ASP.NET MVC e > > por sorte minha não fiquei responsável pela UI... E vi como um amigo sofreu > > pra (ele não programou pra "WEB 1.0") garantir Javascript em todos os > > browsers (ele usou jquery). E uma coisa que não via a anos, ele programou no > > HTML mesmo não sendo negócio.
> > Aí pensei.... estamos voltando ao início de tudo?
> > Mas como não tinha "mexer" com o problema e tinha outras partes do > > sistema pra construir não me preocupei com isso...
> > Mas agora estou em um projeto em que preciso decidir entre o tradicional > > e o novo (velho).
> > Que opções tenho pra um webforms mais "digno" sem usar o ASP.NET MVC? Ou > > pq o ASP.NET MVC é tão bom? Pq me dá o HTML na mão? Isso é bom realmente? > > ou os que estão usando não o tiveram na mão no passado para que pudesse > > comparar com o presente?
> > Por favor não me crucifiquem, não sou o anti-cristo. Só quero entender o > > pq algo que tínhamos no passado e que as pessoas e o mercado festejaram > > quando tiveram a possibilidade se livrar deste controle, agora é a solução > > para todas as nossos problemas técnicos. agora é a melhor opção para > > construir um sistema novo.
> > Não estou discutindo o que está por dentro, quero lidar especificamente > > com a UI. até pq mesmo no ASP tinha uma boa separação de camadas...
> > -- > > Você recebeu esta mensagem porque faz parte do grupo .Net Architects > > hospedado no Google Groups. > > Para postar envie uma mensagem para dotnetarchitects@googlegroups.com > > Para sair do grupo envie uma mensagem para > > dotnetarchitects+unsubscribe@googlegroups.com<dotnetarchitects%2Bunsubscrib e@googlegroups.com> > > Para mais opções visite o grupo em > >http://groups.google.com/group/dotnetarchitects?hl=pt-br
> "E se o mundo não corresponde em todos os aspectos a nossos desejos, é culpa > da ciência ou dos que querem impor seus desejos ao mundo?" - Carl Sagan
Trabalho com webforms há uns 3 anos, é um pouco menos de tempo que tenho de desenvolvimento (yeah, I'm young).
Dizer que MVC não é produtivo é uma grande mentira! E se sua equipe só é produtiva com webforms, então há algo errado.
Trabalhei em projetos PHP(usando CodeIgniter como framework MVC) e Rails por exemplo, sem nenhum tipo de controle drag'n'drop, muito menos IDE, e os projetos foram feitos, entregues, dentro do prazo, com satisfação, etc.
Alguns dizem "No meu sistema não é preciso ter performance e nem validar no W3C, etc". Se você entrega um sistema lento, sem padrões, isso é um problema seu e do seu cliente, não chame isso de produtividade!
Eu não execro os webforms, mas não aceito o argumento de que são mais produtivos por que possuem suporte da IDE e controles drag'n'drop.
> Eu também estou envolvido com programação há mais de 10 anos e, assim como > você, sempre preferi trabalhar com o back-end da aplicação, em vez de ficar > às voltas com UI. Entretanto, não tem como guiar equipes sem conhecer as > tecnologias nas quais elas trabalham a fundo. Trabalhei com WebForms > intensivamente por 6 meses. Foi o suficiente para odiá-lo do fundo do meu > coração. Posso estar sendo extremista, mas qualquer pessoa que se importe > com a elegância de um código se incomoda com o a desorganização que ficam as > páginas ASPX. Ainda mais vendo o HTML que elas geram.
> WebForms só é fácil se você confia 100% no Visual Studio. E mesmo assim ele > te amarra de uma forma inacreditável.
> O ASP.NET MVC ainda está meio verde, mas ele se propõe a se parecer com o > ActionPack do Rails. Se você não conhece, recomendo que estude sobre ele. A > idela é genial.
> Todo mundo aqui na empresa teve um momento de dizer o mesmo que você: "por > que eu vou abandonar tudo o que o WebForms me trouxe (controles, patterns, > etc.) para trabalhar com HTML?". Eu nunca consegui convencer ninguém sem > mostrar código. Por isso realizamos diversos Coding Dojos aqui na empresa > para mostrar como e porque o ASP.NET MVC came to kick WebForms' ass out. É > simplesmente fantástico.
> Entretanto, o único conselho que eu dou pra qualquer pessoa que entre no > ASP.NET MVC é o mesmo que dou para quem aprende Rails ou Karate: entenda o > porquê das coisas antes de criticá-las. Talvez uma solução não lhe pareça a > mais elegante a princípio (como a questão de CoC com os ModelBinders), mas > talvez exista um motivo para ela estar lá.
> Em linhas gerais, e com um argumento extremamente falacioso, eu digo que > ASP.NET MVC rocks porque ele me fez gostar de desenvolver interfaces. > Talvez você também se sinta assim, se pesquisar mais.
> 2010/1/25 Henrique Jacob <analista....@gmail.com>
>> Olá!
>> Não sei se é off, mas vms lá!
>> Seguinte.. já trabalho com programação tem uns 10 anos... antes disso >> brincava de "programar" HTML na época em que o Jornal do Brasil era o >> primeiro jornal na internet e as pessoas faziam coleção de CDs da AOL.
>> Há um bom tempo. Bom mesmo, não preciso programar interfaces com o >> usuário fico responsável por fazer as camadas internas ou montando serviços >> para serem consumidos, etc...
>> De um ano pra cá, fiquei mais próximo da interface, mas mesmo assim >> não tive que meter a mão na massa. Mas hj estou em um projeto em que estou >> usando webform tradicional com MS.AJAX e não estou tendo problemas, como é >> um sistema de uso interno e na demanda de alta performance de UI e nem telas >> escalafobéticas... Achei uma opção interessante...
>> Mas pq estou falando tudo isso??? Bem, nos primórdios de minha vida >> profissional onde comecei com DELPHI e depois fiquei um tempo com o CENTURA >> (SQLWindows) fui apresentado ao ASP e o seu VB Script.
>> Apesar de tudo (VB Script), descobri que gostava de programar pra WEB e >> fiz grandes sistemas em ASP. Inclusive um CMS Multilíngüe que acaba de >> completar 8 anos de produção sem cair que atende muito bem o propósito para >> que foi feito.
>> Me lembro que os maiores problemas daquela época era a respeito de como >> tratar a UI... e como dava trabalho programar javascript que funcionasse em >> todos os browsers e resoluções, manter o estado entre páginas, etc....
>> Aí surgiu o ASP.NET 1.0 e como em um comercial >> das organizações Tabajara esta tecnologia veio para resolver todos os nossos >> problemas técnicos... aos poucos migrei para o .NET e fiz outros tantos >> sistemas. Alguns um grande sucesso outros e outros apenas sistemas....
>> Continuei o meu caminho e cada vez mais me afastei da UI... Então esse >> ano em um grande projeto, a decisão do arquiteto foi usar o ASP.NET MVC e >> por sorte minha não fiquei responsável pela UI... E vi como um amigo sofreu >> pra (ele não programou pra "WEB 1.0") garantir Javascript em todos os >> browsers (ele usou jquery). E uma coisa que não via a anos, ele programou no >> HTML mesmo não sendo negócio.
>> Aí pensei.... estamos voltando ao início de tudo?
>> Mas como não tinha "mexer" com o problema e tinha outras partes do >> sistema pra construir não me preocupei com isso...
>> Mas agora estou em um projeto em que preciso decidir entre o tradicional >> e o novo (velho).
>> Que opções tenho pra um webforms mais "digno" sem usar o ASP.NET MVC? >> Ou pq o ASP.NET MVC é tão bom? Pq me dá o HTML na mão? Isso é bom >> realmente? ou os que estão usando não o tiveram na mão no passado para que >> pudesse comparar com o presente?
>> Por favor não me crucifiquem, não sou o anti-cristo. Só quero entender >> o pq algo que tínhamos no passado e que as pessoas e o mercado festejaram >> quando tiveram a possibilidade se livrar deste controle, agora é a solução >> para todas as nossos problemas técnicos. agora é a melhor opção para >> construir um sistema novo.
>> Não estou discutindo o que está por dentro, quero lidar especificamente >> com a UI. até pq mesmo no ASP tinha uma boa separação de camadas...
>> -- >> Você recebeu esta mensagem porque faz parte do grupo .Net Architects >> hospedado no Google Groups. >> Para postar envie uma mensagem para dotnetarchitects@googlegroups.com >> Para sair do grupo envie uma mensagem para >> dotnetarchitects+unsubscribe@googlegroups.com<dotnetarchitects%2Bunsubscrib e@googlegroups.com> >> Para mais opções visite o grupo em >> http://groups.google.com/group/dotnetarchitects?hl=pt-br
> "E se o mundo não corresponde em todos os aspectos a nossos desejos, é > culpa da ciência ou dos que querem impor seus desejos ao mundo?" - Carl > Sagan
> -- > Você recebeu esta mensagem porque faz parte do grupo .Net Architects > hospedado no Google Groups. > Para postar envie uma mensagem para dotnetarchitects@googlegroups.com > Para sair do grupo envie uma mensagem para > dotnetarchitects+unsubscribe@googlegroups.com<dotnetarchitects%2Bunsubscrib e@googlegroups.com> > Para mais opções visite o grupo em > http://groups.google.com/group/dotnetarchitects?hl=pt-br
Assim como vc nao aceita o argumento que Webforms sao mais produtivos, discordo completamente da sua posicao: "Dizer que MVC não é produtivo é uma grande mentira! E se sua equipe só é produtiva com webforms, então há algo errado."
Trabalho há bastante tempo com webforms e estou comecando agora com MVC e na minha opiniao até o momento Webforms é sim muito mais produtivo do que MVC, pode ser que com o tempo me acostume com o MVC e consiga uma boa produtividade, mas a curva de aprendizado existe, entao pode nao ser algo errado com a equipe.
Não digo que o MVC nao eh produtivo, mas ate o momento posso afirmar que em produtividade ele perde para o Webforms, mas estou procurando estudar e enteder cada vez mais o MVC para ter certeza das suas qualidades e tentar atingir uma melhor produtividade, por isso estou utilizando em alguns projetos.
> Trabalho com webforms há uns 3 anos, é um pouco menos de tempo que tenho de > desenvolvimento (yeah, I'm young).
> Dizer que MVC não é produtivo é uma grande mentira! E se sua equipe só é > produtiva com webforms, então há algo errado.
> Trabalhei em projetos PHP(usando CodeIgniter como framework MVC) e Rails > por exemplo, sem nenhum tipo de controle drag'n'drop, muito menos IDE, e os > projetos foram feitos, entregues, dentro do prazo, com satisfação, etc.
> Alguns dizem "No meu sistema não é preciso ter performance e nem validar no > W3C, etc". Se você entrega um sistema lento, sem padrões, isso é um problema > seu e do seu cliente, não chame isso de produtividade!
> Eu não execro os webforms, mas não aceito o argumento de que são mais > produtivos por que possuem suporte da IDE e controles drag'n'drop.
> 2010/1/25 Juan Pedro A. Lopes <zerova...@gmail.com>
> Eu também estou envolvido com programação há mais de 10 anos e, assim como >> você, sempre preferi trabalhar com o back-end da aplicação, em vez de ficar >> às voltas com UI. Entretanto, não tem como guiar equipes sem conhecer as >> tecnologias nas quais elas trabalham a fundo. Trabalhei com WebForms >> intensivamente por 6 meses. Foi o suficiente para odiá-lo do fundo do meu >> coração. Posso estar sendo extremista, mas qualquer pessoa que se importe >> com a elegância de um código se incomoda com o a desorganização que ficam as >> páginas ASPX. Ainda mais vendo o HTML que elas geram.
>> WebForms só é fácil se você confia 100% no Visual Studio. E mesmo assim >> ele te amarra de uma forma inacreditável.
>> O ASP.NET MVC ainda está meio verde, mas ele se propõe a se parecer com o >> ActionPack do Rails. Se você não conhece, recomendo que estude sobre ele. A >> idela é genial.
>> Todo mundo aqui na empresa teve um momento de dizer o mesmo que você: "por >> que eu vou abandonar tudo o que o WebForms me trouxe (controles, patterns, >> etc.) para trabalhar com HTML?". Eu nunca consegui convencer ninguém sem >> mostrar código. Por isso realizamos diversos Coding Dojos aqui na empresa >> para mostrar como e porque o ASP.NET MVC came to kick WebForms' ass out. >> É simplesmente fantástico.
>> Entretanto, o único conselho que eu dou pra qualquer pessoa que entre no >> ASP.NET MVC é o mesmo que dou para quem aprende Rails ou Karate: entenda >> o porquê das coisas antes de criticá-las. Talvez uma solução não lhe pareça >> a mais elegante a princípio (como a questão de CoC com os ModelBinders), mas >> talvez exista um motivo para ela estar lá.
>> Em linhas gerais, e com um argumento extremamente falacioso, eu digo que >> ASP.NET MVC rocks porque ele me fez gostar de desenvolver interfaces. >> Talvez você também se sinta assim, se pesquisar mais.
>> 2010/1/25 Henrique Jacob <analista....@gmail.com>
>>> Olá!
>>> Não sei se é off, mas vms lá!
>>> Seguinte.. já trabalho com programação tem uns 10 anos... antes >>> disso brincava de "programar" HTML na época em que o Jornal do Brasil era o >>> primeiro jornal na internet e as pessoas faziam coleção de CDs da AOL.
>>> Há um bom tempo. Bom mesmo, não preciso programar interfaces com o >>> usuário fico responsável por fazer as camadas internas ou montando serviços >>> para serem consumidos, etc...
>>> De um ano pra cá, fiquei mais próximo da interface, mas mesmo assim >>> não tive que meter a mão na massa. Mas hj estou em um projeto em que estou >>> usando webform tradicional com MS.AJAX e não estou tendo problemas, como é >>> um sistema de uso interno e na demanda de alta performance de UI e nem telas >>> escalafobéticas... Achei uma opção interessante...
>>> Mas pq estou falando tudo isso??? Bem, nos primórdios de minha vida >>> profissional onde comecei com DELPHI e depois fiquei um tempo com o CENTURA >>> (SQLWindows) fui apresentado ao ASP e o seu VB Script.
>>> Apesar de tudo (VB Script), descobri que gostava de programar pra WEB e >>> fiz grandes sistemas em ASP. Inclusive um CMS Multilíngüe que acaba de >>> completar 8 anos de produção sem cair que atende muito bem o propósito para >>> que foi feito.
>>> Me lembro que os maiores problemas daquela época era a respeito de como >>> tratar a UI... e como dava trabalho programar javascript que funcionasse em >>> todos os browsers e resoluções, manter o estado entre páginas, etc....
>>> Aí surgiu o ASP.NET 1.0 e como em um comercial >>> das organizações Tabajara esta tecnologia veio para resolver todos os nossos >>> problemas técnicos... aos poucos migrei para o .NET e fiz outros tantos >>> sistemas. Alguns um grande sucesso outros e outros apenas sistemas....
>>> Continuei o meu caminho e cada vez mais me afastei da UI... Então esse >>> ano em um grande projeto, a decisão do arquiteto foi usar o ASP.NET MVC >>> e por sorte minha não fiquei responsável pela UI... E vi como um amigo >>> sofreu pra (ele não programou pra "WEB 1.0") garantir Javascript em todos >>> os browsers (ele usou jquery). E uma coisa que não via a anos, ele programou >>> no HTML mesmo não sendo negócio.
>>> Aí pensei.... estamos voltando ao início de tudo?
>>> Mas como não tinha "mexer" com o problema e tinha outras partes do >>> sistema pra construir não me preocupei com isso...
>>> Mas agora estou em um projeto em que preciso decidir entre o >>> tradicional e o novo (velho).
>>> Que opções tenho pra um webforms mais "digno" sem usar o ASP.NET MVC? >>> Ou pq o ASP.NET MVC é tão bom? Pq me dá o HTML na mão? Isso é bom >>> realmente? ou os que estão usando não o tiveram na mão no passado para que >>> pudesse comparar com o presente?
>>> Por favor não me crucifiquem, não sou o anti-cristo. Só quero entender >>> o pq algo que tínhamos no passado e que as pessoas e o mercado festejaram >>> quando tiveram a possibilidade se livrar deste controle, agora é a solução >>> para todas as nossos problemas técnicos. agora é a melhor opção para >>> construir um sistema novo.
>>> Não estou discutindo o que está por dentro, quero lidar >>> especificamente com a UI. até pq mesmo no ASP tinha uma boa separação de >>> camadas...
>>> -- >>> Você recebeu esta mensagem porque faz parte do grupo .Net Architects >>> hospedado no Google Groups. >>> Para postar envie uma mensagem para dotnetarchitects@googlegroups.com >>> Para sair do grupo envie uma mensagem para >>> dotnetarchitects+unsubscribe@googlegroups.com<dotnetarchitects%2Bunsubscrib e@googlegroups.com> >>> Para mais opções visite o grupo em >>> http://groups.google.com/group/dotnetarchitects?hl=pt-br
>> "E se o mundo não corresponde em todos os aspectos a nossos desejos, é >> culpa da ciência ou dos que querem impor seus desejos ao mundo?" - Carl >> Sagan
>> -- >> Você recebeu esta mensagem porque faz parte do grupo .Net Architects >> hospedado no Google Groups. >> Para postar envie uma mensagem para dotnetarchitects@googlegroups.com >> Para sair do grupo envie uma mensagem para >> dotnetarchitects+unsubscribe@googlegroups.com<dotnetarchitects%2Bunsubscrib e@googlegroups.com> >> Para mais opções visite o grupo em >> http://groups.google.com/group/dotnetarchitects?hl=pt-br
> -- > Você recebeu esta mensagem porque faz parte do grupo .Net Architects > hospedado no Google Groups. > Para postar envie uma mensagem para dotnetarchitects@googlegroups.com > Para sair do grupo envie uma mensagem para > dotnetarchitects+unsubscribe@googlegroups.com<dotnetarchitects%2Bunsubscrib e@googlegroups.com> > Para mais opções visite o grupo em > http://groups.google.com/group/dotnetarchitects?hl=pt-br
-- PRABOR - Software Development - fel...@prabor.com.br ---------------------------------------------------------------- Felipe Prata L. Borges MCT, MCPD .Net Framework 2.0: Web Applications Contact: +55 19 9356 1355 msn: felipeu...@hotmail.com skype: felipe.prabor
> Assim como vc nao aceita o argumento que Webforms sao mais produtivos, > discordo completamente da sua posicao: "Dizer que MVC não é produtivo é > uma grande mentira! E se sua equipe só é produtiva com webforms, então há > algo errado."
> Trabalho há bastante tempo com webforms e estou comecando agora com MVC e > na minha opiniao até o momento Webforms é sim muito mais produtivo do que > MVC, pode ser que com o tempo me acostume com o MVC e consiga uma boa > produtividade, mas a curva de aprendizado existe, entao pode nao ser algo > errado com a equipe.
> Não digo que o MVC nao eh produtivo, mas ate o momento posso afirmar que em > produtividade ele perde para o Webforms, mas estou procurando estudar e > enteder cada vez mais o MVC para ter certeza das suas qualidades e tentar > atingir uma melhor produtividade, por isso estou utilizando em alguns > projetos.
>> Trabalho com webforms há uns 3 anos, é um pouco menos de tempo que tenho >> de desenvolvimento (yeah, I'm young).
>> Dizer que MVC não é produtivo é uma grande mentira! E se sua equipe só é >> produtiva com webforms, então há algo errado.
>> Trabalhei em projetos PHP(usando CodeIgniter como framework MVC) e Rails >> por exemplo, sem nenhum tipo de controle drag'n'drop, muito menos IDE, e os >> projetos foram feitos, entregues, dentro do prazo, com satisfação, etc.
>> Alguns dizem "No meu sistema não é preciso ter performance e nem validar >> no W3C, etc". Se você entrega um sistema lento, sem padrões, isso é um >> problema seu e do seu cliente, não chame isso de produtividade!
>> Eu não execro os webforms, mas não aceito o argumento de que são mais >> produtivos por que possuem suporte da IDE e controles drag'n'drop.
>> 2010/1/25 Juan Pedro A. Lopes <zerova...@gmail.com>
>> Eu também estou envolvido com programação há mais de 10 anos e, assim como >>> você, sempre preferi trabalhar com o back-end da aplicação, em vez de ficar >>> às voltas com UI. Entretanto, não tem como guiar equipes sem conhecer as >>> tecnologias nas quais elas trabalham a fundo. Trabalhei com WebForms >>> intensivamente por 6 meses. Foi o suficiente para odiá-lo do fundo do meu >>> coração. Posso estar sendo extremista, mas qualquer pessoa que se importe >>> com a elegância de um código se incomoda com o a desorganização que ficam as >>> páginas ASPX. Ainda mais vendo o HTML que elas geram.
>>> WebForms só é fácil se você confia 100% no Visual Studio. E mesmo assim >>> ele te amarra de uma forma inacreditável.
>>> O ASP.NET MVC ainda está meio verde, mas ele se propõe a se parecer com >>> o ActionPack do Rails. Se você não conhece, recomendo que estude sobre ele. >>> A idela é genial.
>>> Todo mundo aqui na empresa teve um momento de dizer o mesmo que você: >>> "por que eu vou abandonar tudo o que o WebForms me trouxe (controles, >>> patterns, etc.) para trabalhar com HTML?". Eu nunca consegui convencer >>> ninguém sem mostrar código. Por isso realizamos diversos Coding Dojos aqui >>> na empresa para mostrar como e porque o ASP.NET MVC came to kick >>> WebForms' ass out. É simplesmente fantástico.
>>> Entretanto, o único conselho que eu dou pra qualquer pessoa que entre no >>> ASP.NET MVC é o mesmo que dou para quem aprende Rails ou Karate: entenda >>> o porquê das coisas antes de criticá-las. Talvez uma solução não lhe pareça >>> a mais elegante a princípio (como a questão de CoC com os ModelBinders), mas >>> talvez exista um motivo para ela estar lá.
>>> Em linhas gerais, e com um argumento extremamente falacioso, eu digo que >>> ASP.NET MVC rocks porque ele me fez gostar de desenvolver interfaces. >>> Talvez você também se sinta assim, se pesquisar mais.
>>> 2010/1/25 Henrique Jacob <analista....@gmail.com>
>>>> Olá!
>>>> Não sei se é off, mas vms lá!
>>>> Seguinte.. já trabalho com programação tem uns 10 anos... antes >>>> disso brincava de "programar" HTML na época em que o Jornal do Brasil era o >>>> primeiro jornal na internet e as pessoas faziam coleção de CDs da AOL.
>>>> Há um bom tempo. Bom mesmo, não preciso programar interfaces com o >>>> usuário fico responsável por fazer as camadas internas ou montando serviços >>>> para serem consumidos, etc...
>>>> De um ano pra cá, fiquei mais próximo da interface, mas mesmo assim >>>> não tive que meter a mão na massa. Mas hj estou em um projeto em que estou >>>> usando webform tradicional com MS.AJAX e não estou tendo problemas, como é >>>> um sistema de uso interno e na demanda de alta performance de UI e nem telas >>>> escalafobéticas... Achei uma opção interessante...
>>>> Mas pq estou falando tudo isso??? Bem, nos primórdios de minha vida >>>> profissional onde comecei com DELPHI e depois fiquei um tempo com o CENTURA >>>> (SQLWindows) fui apresentado ao ASP e o seu VB Script.
>>>> Apesar de tudo (VB Script), descobri que gostava de programar pra WEB >>>> e fiz grandes sistemas em ASP. Inclusive um CMS Multilíngüe que acaba de >>>> completar 8 anos de produção sem cair que atende muito bem o propósito para >>>> que foi feito.
>>>> Me lembro que os maiores problemas daquela época era a respeito de >>>> como tratar a UI... e como dava trabalho programar javascript que >>>> funcionasse em todos os browsers e resoluções, manter o estado entre >>>> páginas, etc....
>>>> Aí surgiu o ASP.NET 1.0 e como em um comercial >>>> das organizações Tabajara esta tecnologia veio para resolver todos os nossos >>>> problemas técnicos... aos poucos migrei para o .NET e fiz outros tantos >>>> sistemas. Alguns um grande sucesso outros e outros apenas sistemas....
>>>> Continuei o meu caminho e cada vez mais me afastei da UI... Então esse >>>> ano em um grande projeto, a decisão do arquiteto foi usar o ASP.NET MVC >>>> e por sorte minha não fiquei responsável pela UI... E vi como um amigo >>>> sofreu pra (ele não programou pra "WEB 1.0") garantir Javascript em todos >>>> os browsers (ele usou jquery). E uma coisa que não via a anos, ele programou >>>> no HTML mesmo não sendo negócio.
>>>> Aí pensei.... estamos voltando ao início de tudo?
>>>> Mas como não tinha "mexer" com o problema e tinha outras partes do >>>> sistema pra construir não me preocupei com isso...
>>>> Mas agora estou em um projeto em que preciso decidir entre o >>>> tradicional e o novo (velho).
>>>> Que opções tenho pra um webforms mais "digno" sem usar o ASP.NET MVC? >>>> Ou pq o ASP.NET MVC é tão bom? Pq me dá o HTML na mão? Isso é bom >>>> realmente? ou os que estão usando não o tiveram na mão no passado para que >>>> pudesse comparar com o presente?
>>>> Por favor não me crucifiquem, não sou o anti-cristo. Só quero >>>> entender o pq algo que tínhamos no passado e que as pessoas e o mercado >>>> festejaram quando tiveram a possibilidade se livrar deste controle, agora é >>>> a solução para todas as nossos problemas técnicos. agora é a melhor opção >>>> para construir um sistema novo.
>>>> Não estou discutindo o que está por dentro, quero lidar >>>> especificamente com a UI. até pq mesmo no ASP tinha uma boa separação de >>>> camadas...
>>>> -- >>>> Você recebeu esta mensagem porque faz parte do grupo .Net Architects >>>> hospedado no Google Groups. >>>> Para postar envie uma mensagem para dotnetarchitects@googlegroups.com >>>> Para sair do grupo envie uma mensagem para >>>> dotnetarchitects+unsubscribe@googlegroups.com<dotnetarchitects%2Bunsubscrib e@googlegroups.com> >>>> Para mais opções visite o grupo em >>>> http://groups.google.com/group/dotnetarchitects?hl=pt-br
>>> "E se o mundo não corresponde em todos os aspectos a nossos desejos, é >>> culpa da ciência ou dos que querem impor seus desejos ao mundo?" - Carl >>> Sagan
>>> -- >>> Você recebeu esta mensagem porque faz parte do grupo .Net Architects >>> hospedado no Google Groups. >>> Para postar envie uma mensagem para dotnetarchitects@googlegroups.com >>> Para sair do grupo envie uma mensagem para >>> dotnetarchitects+unsubscribe@googlegroups.com<dotnetarchitects%2Bunsubscrib e@googlegroups.com> >>> Para mais opções visite o grupo em >>> http://groups.google.com/group/dotnetarchitects?hl=pt-br
>> -- >> Você recebeu esta mensagem porque faz parte do grupo .Net Architects >> hospedado no Google Groups. >> Para postar envie uma mensagem para dotnetarchitects@googlegroups.com >> Para sair do grupo envie uma mensagem para >> dotnetarchitects+unsubscribe@googlegroups.com<dotnetarchitects%2Bunsubscrib e@googlegroups.com> >> Para mais opções visite o grupo em >> http://groups.google.com/group/dotnetarchitects?hl=pt-br
> -- > PRABOR - Software Development - fel...@prabor.com.br > ---------------------------------------------------------------- > Felipe Prata L. Borges > MCT, MCPD .Net Framework 2.0: Web Applications > Contact: +55 19 9356 1355 > msn: felipeu...@hotmail.com > skype: felipe.prabor
> -- > Você recebeu esta mensagem porque faz parte do grupo .Net Architects > hospedado no Google Groups. > Para postar envie uma mensagem para
WebForms é mais produtivo SIM e ponto, não venham me dizer que fazer uma grid aninhada é mais simples no MVC porque não é.
Se eu ligar o foda-se para a arquitetura e arrastar e soltar tudo, espalhar um milhão de connection string no meu código eu faço muitas coisas mais rápidas do que muita gente, meu html estará bichado? pode-se ser, mas e daí? Argumento de validar W3C é bobeira já tive um HTML validado pelo W3C que não rodava nos browsers igualmente. Produtividade tem haver velocidade e qualidade, velocidade é do lado desenvolvedor, qualidade é percepção do cliente.
Entre WebForm e MVC, Eu posso trabalhar como se fosse MVC no WebForm, e continuar com as regalias do WebForm. Posso misturar tudo e ficar uma merda de dar manutenção.
Falar que MVC é uma maravilha é idiotice, pois nenhuma tecnologia é tão maravilhosa assim. MVC ser melhor que WebForms outra idiotice.
Será que o padrão de projeto MVC é tão novo assim, que os arquitetos da Microsoft IGNORARAM ao inventar o WebForm? Se o fizeram também tinham uma razão. Se agora estão trazendo de volta também deve ter um motivo.
Se alguém me perguntar com qual dos dois eu fico? Respondo sem pensar WebForms. Quer mudar/evoluir na UI? Vá para o Silverlight. Esse sim merece ser estudado, curva de aprendizado, retrabalho, etc.
Silverlight é uma evolução da UI e não um modelo anterior melhorado, pois isso que o MVC é, um WebForms melhorado.
Vocês sabiam que WebForms também é um padrão de projeto chamado MVP, Model-View-Presenter, logo ele é a representação abstrata de algum padrão de problema. Da mesma forma que o MVC também o é. Existem melhoria no MVC que ajudam no desenvolvimento, sem dúvida. Mas que ele é apenas uma versão melhorada do WebForm não dá para negar.
MVC não muda paradigmas, apenas é uma solução alternativa para um problema conhecido.
> Assim como vc nao aceita o argumento que Webforms sao mais produtivos, >> discordo completamente da sua posicao: "Dizer que MVC não é produtivo é >> uma grande mentira! E se sua equipe só é produtiva com webforms, então há >> algo errado."
>> Trabalho há bastante tempo com webforms e estou comecando agora com MVC e >> na minha opiniao até o momento Webforms é sim muito mais produtivo do que >> MVC, pode ser que com o tempo me acostume com o MVC e consiga uma boa >> produtividade, mas a curva de aprendizado existe, entao pode nao ser algo >> errado com a equipe.
>> Não digo que o MVC nao eh produtivo, mas ate o momento posso afirmar que >> em produtividade ele perde para o Webforms, mas estou procurando estudar e >> enteder cada vez mais o MVC para ter certeza das suas qualidades e tentar >> atingir uma melhor produtividade, por isso estou utilizando em alguns >> projetos.
>>> Trabalho com webforms há uns 3 anos, é um pouco menos de tempo que tenho >>> de desenvolvimento (yeah, I'm young).
>>> Dizer que MVC não é produtivo é uma grande mentira! E se sua equipe só é >>> produtiva com webforms, então há algo errado.
>>> Trabalhei em projetos PHP(usando CodeIgniter como framework MVC) e Rails >>> por exemplo, sem nenhum tipo de controle drag'n'drop, muito menos IDE, e os >>> projetos foram feitos, entregues, dentro do prazo, com satisfação, etc.
>>> Alguns dizem "No meu sistema não é preciso ter performance e nem validar >>> no W3C, etc". Se você entrega um sistema lento, sem padrões, isso é um >>> problema seu e do seu cliente, não chame isso de produtividade!
>>> Eu não execro os webforms, mas não aceito o argumento de que são mais >>> produtivos por que possuem suporte da IDE e controles drag'n'drop.
>>> 2010/1/25 Juan Pedro A. Lopes <zerova...@gmail.com>
>>> Eu também estou envolvido com programação há mais de 10 anos e, assim >>>> como você, sempre preferi trabalhar com o back-end da aplicação, em vez de >>>> ficar às voltas com UI. Entretanto, não tem como guiar equipes sem conhecer >>>> as tecnologias nas quais elas trabalham a fundo. Trabalhei com WebForms >>>> intensivamente por 6 meses. Foi o suficiente para odiá-lo do fundo do meu >>>> coração. Posso estar sendo extremista, mas qualquer pessoa que se importe >>>> com a elegância de um código se incomoda com o a desorganização que ficam as >>>> páginas ASPX. Ainda mais vendo o HTML que elas geram.
>>>> WebForms só é fácil se você confia 100% no Visual Studio. E mesmo assim >>>> ele te amarra de uma forma inacreditável.
>>>> O ASP.NET MVC ainda está meio verde, mas ele se propõe a se parecer com >>>> o ActionPack do Rails. Se você não conhece, recomendo que estude sobre ele. >>>> A idela é genial.
>>>> Todo mundo aqui na empresa teve um momento de dizer o mesmo que você: >>>> "por que eu vou abandonar tudo o que o WebForms me trouxe (controles, >>>> patterns, etc.) para trabalhar com HTML?". Eu nunca consegui convencer >>>> ninguém sem mostrar código. Por isso realizamos diversos Coding Dojos aqui >>>> na empresa para mostrar como e porque o ASP.NET MVC came to kick >>>> WebForms' ass out. É simplesmente fantástico.
>>>> Entretanto, o único conselho que eu dou pra qualquer pessoa que entre no >>>> ASP.NET MVC é o mesmo que dou para quem aprende Rails ou Karate: >>>> entenda o porquê das coisas antes de criticá-las. Talvez uma solução não lhe >>>> pareça a mais elegante a princípio (como a questão de CoC com os >>>> ModelBinders), mas talvez exista um motivo para ela estar lá.
>>>> Em linhas gerais, e com um argumento extremamente falacioso, eu digo que >>>> ASP.NET MVC rocks porque ele me fez gostar de desenvolver interfaces. >>>> Talvez você também se sinta assim, se pesquisar mais.
>>>> 2010/1/25 Henrique Jacob <analista....@gmail.com>
>>>>> Olá!
>>>>> Não sei se é off, mas vms lá!
>>>>> Seguinte.. já trabalho com programação tem uns 10 anos... antes >>>>> disso brincava de "programar" HTML na época em que o Jornal do Brasil era o >>>>> primeiro jornal na internet e as pessoas faziam coleção de CDs da AOL.
>>>>> Há um bom tempo. Bom mesmo, não preciso programar interfaces com o >>>>> usuário fico responsável por fazer as camadas internas ou montando serviços >>>>> para serem consumidos, etc...
>>>>> De um ano pra cá, fiquei mais próximo da interface, mas mesmo assim >>>>> não tive que meter a mão na massa. Mas hj estou em um projeto em que estou >>>>> usando webform tradicional com MS.AJAX e não estou tendo problemas, como é >>>>> um sistema de uso interno e na demanda de alta performance de UI e nem telas >>>>> escalafobéticas... Achei uma opção interessante...
>>>>> Mas pq estou falando tudo isso??? Bem, nos primórdios de minha vida >>>>> profissional onde comecei com DELPHI e depois fiquei um tempo com o CENTURA >>>>> (SQLWindows) fui apresentado ao ASP e o seu VB Script.
>>>>> Apesar de tudo (VB Script), descobri que gostava de programar pra WEB >>>>> e fiz grandes sistemas em ASP. Inclusive um CMS Multilíngüe que acaba de >>>>> completar 8 anos de produção sem cair que atende muito bem o propósito para >>>>> que foi feito.
>>>>> Me lembro que os maiores problemas daquela época era a respeito de >>>>> como tratar a UI... e como dava trabalho programar javascript que >>>>> funcionasse em todos os browsers e resoluções, manter o estado entre >>>>> páginas, etc....
>>>>> Aí surgiu o ASP.NET 1.0 e como em um comercial >>>>> das organizações Tabajara esta tecnologia veio para resolver todos os nossos >>>>> problemas técnicos... aos poucos migrei para o .NET e fiz outros tantos >>>>> sistemas. Alguns um grande sucesso outros e outros apenas sistemas....
>>>>> Continuei o meu caminho e cada vez mais me afastei da UI... Então >>>>> esse ano em um grande projeto, a decisão do arquiteto foi usar o >>>>> ASP.NET MVC e por sorte minha não fiquei responsável pela UI... E vi >>>>> como um amigo sofreu pra (ele não programou pra "WEB 1.0") garantir >>>>> Javascript em todos os browsers (ele usou jquery). E uma coisa que não via >>>>> a anos, ele programou no HTML mesmo não sendo negócio.
>>>>> Aí pensei.... estamos voltando ao início de tudo?
>>>>> Mas como não tinha "mexer" com o problema e tinha outras partes do >>>>> sistema pra construir não me preocupei com isso...
>>>>> Mas agora estou em um projeto em que preciso decidir entre o >>>>> tradicional e o novo (velho).
>>>>> Que opções tenho pra um webforms mais "digno" sem usar o ASP.NETMVC? Ou pq o >>>>> ASP.NET MVC é tão bom? Pq me dá o HTML na mão? Isso é bom realmente? >>>>> ou os que estão usando não o tiveram na mão no passado para que pudesse >>>>> comparar com o presente?
>>>>> Por favor não me crucifiquem, não sou o anti-cristo. Só quero >>>>> entender o pq algo que tínhamos no passado e que as pessoas e o mercado >>>>> festejaram quando tiveram a possibilidade se livrar deste controle, agora é >>>>> a solução para todas as nossos problemas técnicos.
> WebForms é mais produtivo SIM e ponto, não venham me dizer que fazer uma > grid aninhada é mais simples no MVC porque não é.
> Se eu ligar o foda-se para a arquitetura e arrastar e soltar tudo, espalhar > um milhão de connection string no meu código eu faço muitas coisas mais > rápidas do que muita gente, meu html estará bichado? pode-se ser, mas e daí? > Argumento de validar W3C é bobeira já tive um HTML validado pelo W3C que não > rodava nos browsers igualmente. Produtividade tem haver velocidade e > qualidade, velocidade é do lado desenvolvedor, qualidade é percepção do > cliente.
> Entre WebForm e MVC, Eu posso trabalhar como se fosse MVC no WebForm, e > continuar com as regalias do WebForm. Posso misturar tudo e ficar uma merda > de dar manutenção.
> Falar que MVC é uma maravilha é idiotice, pois nenhuma tecnologia é tão > maravilhosa assim. MVC ser melhor que WebForms outra idiotice.
> Será que o padrão de projeto MVC é tão novo assim, que os arquitetos da > Microsoft IGNORARAM ao inventar o WebForm? Se o fizeram também tinham uma > razão. Se agora estão trazendo de volta também deve ter um motivo.
> Se alguém me perguntar com qual dos dois eu fico? Respondo sem pensar > WebForms. Quer mudar/evoluir na UI? Vá para o Silverlight. Esse sim merece > ser estudado, curva de aprendizado, retrabalho, etc.
> Silverlight é uma evolução da UI e não um modelo anterior melhorado, pois > isso que o MVC é, um WebForms melhorado.
> Vocês sabiam que WebForms também é um padrão de projeto chamado MVP, > Model-View-Presenter, logo ele é a representação abstrata de algum padrão de > problema. Da mesma forma que o MVC também o é. Existem melhoria no MVC que > ajudam no desenvolvimento, sem dúvida. Mas que ele é apenas uma versão > melhorada do WebForm não dá para negar.
> MVC não muda paradigmas, apenas é uma solução alternativa para um problema > conhecido.
>> Assim como vc nao aceita o argumento que Webforms sao mais produtivos, >>> discordo completamente da sua posicao: "Dizer que MVC não é produtivo é >>> uma grande mentira! E se sua equipe só é produtiva com webforms, então há >>> algo errado."
>>> Trabalho há bastante tempo com webforms e estou comecando agora com MVC e >>> na minha opiniao até o momento Webforms é sim muito mais produtivo do que >>> MVC, pode ser que com o tempo me acostume com o MVC e consiga uma boa >>> produtividade, mas a curva de aprendizado existe, entao pode nao ser algo >>> errado com a equipe.
>>> Não digo que o MVC nao eh produtivo, mas ate o momento posso afirmar que >>> em produtividade ele perde para o Webforms, mas estou procurando estudar e >>> enteder cada vez mais o MVC para ter certeza das suas qualidades e tentar >>> atingir uma melhor produtividade, por isso estou utilizando em alguns >>> projetos.
>>>> Trabalho com webforms há uns 3 anos, é um pouco menos de tempo que tenho >>>> de desenvolvimento (yeah, I'm young).
>>>> Dizer que MVC não é produtivo é uma grande mentira! E se sua equipe só é >>>> produtiva com webforms, então há algo errado.
>>>> Trabalhei em projetos PHP(usando CodeIgniter como framework MVC) e Rails >>>> por exemplo, sem nenhum tipo de controle drag'n'drop, muito menos IDE, e os >>>> projetos foram feitos, entregues, dentro do prazo, com satisfação, etc.
>>>> Alguns dizem "No meu sistema não é preciso ter performance e nem validar >>>> no W3C, etc". Se você entrega um sistema lento, sem padrões, isso é um >>>> problema seu e do seu cliente, não chame isso de produtividade!
>>>> Eu não execro os webforms, mas não aceito o argumento de que são mais >>>> produtivos por que possuem suporte da IDE e controles drag'n'drop.
>>>> 2010/1/25 Juan Pedro A. Lopes <zerova...@gmail.com>
>>>> Eu também estou envolvido com programação há mais de 10 anos e, assim >>>>> como você, sempre preferi trabalhar com o back-end da aplicação, em vez de >>>>> ficar às voltas com UI. Entretanto, não tem como guiar equipes sem conhecer >>>>> as tecnologias nas quais elas trabalham a fundo. Trabalhei com WebForms >>>>> intensivamente por 6 meses. Foi o suficiente para odiá-lo do fundo do meu >>>>> coração. Posso estar sendo extremista, mas qualquer pessoa que se importe >>>>> com a elegância de um código se incomoda com o a desorganização que ficam as >>>>> páginas ASPX. Ainda mais vendo o HTML que elas geram.
>>>>> WebForms só é fácil se você confia 100% no Visual Studio. E mesmo assim >>>>> ele te amarra de uma forma inacreditável.
>>>>> O ASP.NET MVC ainda está meio verde, mas ele se propõe a se parecer >>>>> com o ActionPack do Rails. Se você não conhece, recomendo que estude sobre >>>>> ele. A idela é genial.
>>>>> Todo mundo aqui na empresa teve um momento de dizer o mesmo que você: >>>>> "por que eu vou abandonar tudo o que o WebForms me trouxe (controles, >>>>> patterns, etc.) para trabalhar com HTML?". Eu nunca consegui convencer >>>>> ninguém sem mostrar código. Por isso realizamos diversos Coding Dojos aqui >>>>> na empresa para mostrar como e porque o ASP.NET MVC came to kick >>>>> WebForms' ass out. É simplesmente fantástico.
>>>>> Entretanto, o único conselho que eu dou pra qualquer pessoa que entre >>>>> no ASP.NET MVC é o mesmo que dou para quem aprende Rails ou Karate: >>>>> entenda o porquê das coisas antes de criticá-las. Talvez uma solução não lhe >>>>> pareça a mais elegante a princípio (como a questão de CoC com os >>>>> ModelBinders), mas talvez exista um motivo para ela estar lá.
>>>>> Em linhas gerais, e com um argumento extremamente falacioso, eu digo >>>>> que ASP.NET MVC rocks porque ele me fez gostar de desenvolver >>>>> interfaces. Talvez você também se sinta assim, se pesquisar mais.
>>>>> 2010/1/25 Henrique Jacob <analista....@gmail.com>
>>>>>> Olá!
>>>>>> Não sei se é off, mas vms lá!
>>>>>> Seguinte.. já trabalho com programação tem uns 10 anos... antes >>>>>> disso brincava de "programar" HTML na época em que o Jornal do Brasil era o >>>>>> primeiro jornal na internet e as pessoas faziam coleção de CDs da AOL.
>>>>>> Há um bom tempo. Bom mesmo, não preciso programar interfaces com o >>>>>> usuário fico responsável por fazer as camadas internas ou montando serviços >>>>>> para serem consumidos, etc...
>>>>>> De um ano pra cá, fiquei mais próximo da interface, mas mesmo >>>>>> assim não tive que meter a mão na massa. Mas hj estou em um projeto em que >>>>>> estou usando webform tradicional com MS.AJAX e não estou tendo problemas, >>>>>> como é um sistema de uso interno e na demanda de alta performance de UI e >>>>>> nem telas escalafobéticas... Achei uma opção interessante...
>>>>>> Mas pq estou falando tudo isso??? Bem, nos primórdios de minha vida >>>>>> profissional onde comecei com DELPHI e depois fiquei um tempo com o CENTURA >>>>>> (SQLWindows) fui apresentado ao ASP e o seu VB Script.
>>>>>> Apesar de tudo (VB Script), descobri que gostava de programar pra >>>>>> WEB e fiz grandes sistemas em ASP. Inclusive um CMS Multilíngüe que acaba de >>>>>> completar 8 anos de produção sem cair que atende muito bem o propósito para >>>>>> que foi feito.
>>>>>> Me lembro que os maiores problemas daquela época era a respeito de >>>>>> como tratar a UI... e como dava trabalho programar javascript que >>>>>> funcionasse em todos os browsers e resoluções, manter o estado entre >>>>>> páginas, etc....
>>>>>> Aí surgiu o ASP.NET 1.0 e como em um comercial >>>>>> das organizações Tabajara esta tecnologia veio para resolver todos os nossos >>>>>> problemas técnicos... aos poucos migrei para o .NET e fiz outros tantos >>>>>> sistemas. Alguns um grande sucesso outros e outros apenas sistemas....
>>>>>> Continuei o meu caminho e cada vez mais me afastei da UI... Então >>>>>> esse ano em um grande projeto, a decisão do arquiteto foi usar o >>>>>> ASP.NET MVC e por sorte minha não fiquei responsável pela UI... E vi >>>>>> como um amigo sofreu pra (ele não programou pra "WEB 1.0") garantir >>>>>> Javascript em todos os browsers (ele usou jquery). E uma coisa que não via >>>>>> a anos, ele programou no HTML mesmo não sendo negócio.
>>>>>> Aí pensei.... estamos voltando ao início de tudo?
>>>>>> Mas como não tinha "mexer" com o problema e tinha outras partes do >>>>>> sistema pra construir não me preocupei com isso...
>>>>>> Mas agora estou em um projeto em que preciso decidir entre o >>>>>> tradicional e o novo (velho).
Pode-se comparar produtividade quando se tem domínio nas tecnologias !!!
Dizer que webforms é mais produtivo do que o Asp.Net MVC sem conhecer o mvc bem, é um equívoco, e vice-versa !!
Eu, pessoalmente, gosto muito do MVC. Tenho um controle muito bom sobre tudo e tudo funciona bem para minhas necessidades. Nunca gostei do arrastar e soltar .... o não saber o que será gerado ou o funcionamento sempre me "assustou".
Com o MVC tenho controle sobre tudo que está funcionando. Produtividade é relativa, enquanto o webforms usa e abusa dos componentes que rodam no server, o MVC abusa do jQuery (e eu fico com o jQuery ... hehehe). Há plugins para jQuery em tudo que é canto de tudo que é tipo e para tudo que é funcionalidade ... e é apenas um js (normalmente pequeno) que pode inclusive ser aberto e retirado o que não será útil para ter melhor performance !!!
Arrastar um TextBox e soltar na tela ou escrever um Html.TextBox não tem muita diferença !! (apesar de podermos arrastar controles Html no MVC também !!!)
Analisar produtividade é para quem conhece realmente a fundo as duas tecnologias !!! Com certeza código limpo é possível obter com as duas tecnologias, porém talvez não com a mesma facilidade. Enquanto uma é nativamente mais "suja", a outra é nativamente mais "limpa" ... mas ambas podem ser "sujas" ou "limpas", depende de quem usa !!
> Assim como vc nao aceita o argumento que Webforms sao mais produtivos, >> discordo completamente da sua posicao: "Dizer que MVC não é produtivo é >> uma grande mentira! E se sua equipe só é produtiva com webforms, então há >> algo errado."
>> Trabalho há bastante tempo com webforms e estou comecando agora com MVC e >> na minha opiniao até o momento Webforms é sim muito mais produtivo do que >> MVC, pode ser que com o tempo me acostume com o MVC e consiga uma boa >> produtividade, mas a curva de aprendizado existe, entao pode nao ser algo >> errado com a equipe.
>> Não digo que o MVC nao eh produtivo, mas ate o momento posso afirmar que >> em produtividade ele perde para o Webforms, mas estou procurando estudar e >> enteder cada vez mais o MVC para ter certeza das suas qualidades e tentar >> atingir uma melhor produtividade, por isso estou utilizando em alguns >> projetos.
>>> Trabalho com webforms há uns 3 anos, é um pouco menos de tempo que tenho >>> de desenvolvimento (yeah, I'm young).
>>> Dizer que MVC não é produtivo é uma grande mentira! E se sua equipe só é >>> produtiva com webforms, então há algo errado.
>>> Trabalhei em projetos PHP(usando CodeIgniter como framework MVC) e Rails >>> por exemplo, sem nenhum tipo de controle drag'n'drop, muito menos IDE, e os >>> projetos foram feitos, entregues, dentro do prazo, com satisfação, etc.
>>> Alguns dizem "No meu sistema não é preciso ter performance e nem validar >>> no W3C, etc". Se você entrega um sistema lento, sem padrões, isso é um >>> problema seu e do seu cliente, não chame isso de produtividade!
>>> Eu não execro os webforms, mas não aceito o argumento de que são mais >>> produtivos por que possuem suporte da IDE e controles drag'n'drop.
>>> 2010/1/25 Juan Pedro A. Lopes <zerova...@gmail.com>
>>> Eu também estou envolvido com programação há mais de 10 anos e, assim >>>> como você, sempre preferi trabalhar com o back-end da aplicação, em vez de >>>> ficar às voltas com UI. Entretanto, não tem como guiar equipes sem conhecer >>>> as tecnologias nas quais elas trabalham a fundo. Trabalhei com WebForms >>>> intensivamente por 6 meses. Foi o suficiente para odiá-lo do fundo do meu >>>> coração. Posso estar sendo extremista, mas qualquer pessoa que se importe >>>> com a elegância de um código se incomoda com o a desorganização que ficam as >>>> páginas ASPX. Ainda mais vendo o HTML que elas geram.
>>>> WebForms só é fácil se você confia 100% no Visual Studio. E mesmo assim >>>> ele te amarra de uma forma inacreditável.
>>>> O ASP.NET MVC ainda está meio verde, mas ele se propõe a se parecer com >>>> o ActionPack do Rails. Se você não conhece, recomendo que estude sobre ele. >>>> A idela é genial.
>>>> Todo mundo aqui na empresa teve um momento de dizer o mesmo que você: >>>> "por que eu vou abandonar tudo o que o WebForms me trouxe (controles, >>>> patterns, etc.) para trabalhar com HTML?". Eu nunca consegui convencer >>>> ninguém sem mostrar código. Por isso realizamos diversos Coding Dojos aqui >>>> na empresa para mostrar como e porque o ASP.NET MVC came to kick >>>> WebForms' ass out. É simplesmente fantástico.
>>>> Entretanto, o único conselho que eu dou pra qualquer pessoa que entre no >>>> ASP.NET MVC é o mesmo que dou para quem aprende Rails ou Karate: >>>> entenda o porquê das coisas antes de criticá-las. Talvez uma solução não lhe >>>> pareça a mais elegante a princípio (como a questão de CoC com os >>>> ModelBinders), mas talvez exista um motivo para ela estar lá.
>>>> Em linhas gerais, e com um argumento extremamente falacioso, eu digo que >>>> ASP.NET MVC rocks porque ele me fez gostar de desenvolver interfaces. >>>> Talvez você também se sinta assim, se pesquisar mais.
>>>> 2010/1/25 Henrique Jacob <analista....@gmail.com>
>>>>> Olá!
>>>>> Não sei se é off, mas vms lá!
>>>>> Seguinte.. já trabalho com programação tem uns 10 anos... antes >>>>> disso brincava de "programar" HTML na época em que o Jornal do Brasil era o >>>>> primeiro jornal na internet e as pessoas faziam coleção de CDs da AOL.
>>>>> Há um bom tempo. Bom mesmo, não preciso programar interfaces com o >>>>> usuário fico responsável por fazer as camadas internas ou montando serviços >>>>> para serem consumidos, etc...
>>>>> De um ano pra cá, fiquei mais próximo da interface, mas mesmo assim >>>>> não tive que meter a mão na massa. Mas hj estou em um projeto em que estou >>>>> usando webform tradicional com MS.AJAX e não estou tendo problemas, como é >>>>> um sistema de uso interno e na demanda de alta performance de UI e nem telas >>>>> escalafobéticas... Achei uma opção interessante...
>>>>> Mas pq estou falando tudo isso??? Bem, nos primórdios de minha vida >>>>> profissional onde comecei com DELPHI e depois fiquei um tempo com o CENTURA >>>>> (SQLWindows) fui apresentado ao ASP e o seu VB Script.
>>>>> Apesar de tudo (VB Script), descobri que gostava de programar pra WEB >>>>> e fiz grandes sistemas em ASP. Inclusive um CMS Multilíngüe que acaba de >>>>> completar 8 anos de produção sem cair que atende muito bem o propósito para >>>>> que foi feito.
>>>>> Me lembro que os maiores problemas daquela época era a respeito de >>>>> como tratar a UI... e como dava trabalho programar javascript que >>>>> funcionasse em todos os browsers e resoluções, manter o estado entre >>>>> páginas, etc....
>>>>> Aí surgiu o ASP.NET 1.0 e como em um comercial >>>>> das organizações Tabajara esta tecnologia veio para resolver todos os nossos >>>>> problemas técnicos... aos poucos migrei para o .NET e fiz outros tantos >>>>> sistemas. Alguns um grande sucesso outros e outros apenas sistemas....
>>>>> Continuei o meu caminho e cada vez mais me afastei da UI... Então >>>>> esse ano em um grande projeto, a decisão do arquiteto foi usar o >>>>> ASP.NET MVC e por sorte minha não fiquei responsável pela UI... E vi >>>>> como um amigo sofreu pra (ele não programou pra "WEB 1.0") garantir >>>>> Javascript em todos os browsers (ele usou jquery). E uma coisa que não via >>>>> a anos, ele programou no HTML mesmo não sendo negócio.
>>>>> Aí pensei.... estamos voltando ao início de tudo?
>>>>> Mas como não tinha "mexer" com o problema e tinha outras partes do >>>>> sistema pra construir não me preocupei com isso...
>>>>> Mas agora estou em um projeto em que preciso decidir entre o >>>>> tradicional e o novo (velho).
>>>>> Que opções tenho pra um webforms mais "digno" sem usar o ASP.NETMVC? Ou pq o >>>>> ASP.NET MVC é tão bom? Pq me dá o HTML na mão? Isso é bom realmente? >>>>> ou os que estão usando não o tiveram na mão no passado para que pudesse >>>>> comparar com o presente?
>>>>> Por favor não me crucifiquem, não sou o anti-cristo. Só quero >>>>> entender o pq algo que tínhamos no passado e que as pessoas e o mercado >>>>> festejaram quando tiveram a possibilidade se livrar deste controle, agora é >>>>> a solução para todas as nossos problemas técnicos. agora é a melhor opção >>>>> para construir um sistema novo.
>>>>> Não estou discutindo o que está por dentro, quero lidar >>>>> especificamente com a UI. até pq mesmo no ASP tinha uma boa separação de >>>>> camadas...
>>>>> -- >>>>> Você recebeu esta mensagem porque faz parte do grupo .Net Architects >>>>> hospedado no Google Groups. >>>>> Para postar envie uma mensagem para dotnetarchitects@googlegroups.com >>>>> Para sair do grupo envie uma mensagem para >>>>> dotnetarchitects+unsubscribe@googlegroups.com<dotnetarchitects%2Bunsubscrib e@googlegroups.com> >>>>> Para mais opções visite o grupo em
Concordo contigo Ricardo, e diria ainda que produtividade não pode apennas ser medida no "tempo de desenvolvimento de determinada feature". Produtividade se mede no dia-a-dia, no decorrer do projeto, e principlamente, NA MODIFICAÇÃO DO PROJETO.
Pra mim produtividade não é disparar um cronômetro e ver quem desenha um grid primeiro.
> Pode-se comparar produtividade quando se tem domínio nas tecnologias !!!
> Dizer que webforms é mais produtivo do que o Asp.Net MVC sem conhecer o mvc > bem, é um equívoco, e vice-versa !!
> Eu, pessoalmente, gosto muito do MVC. Tenho um controle muito bom sobre > tudo e tudo funciona bem para minhas necessidades. Nunca gostei do arrastar > e soltar .... o não saber o que será gerado ou o funcionamento sempre me > "assustou".
> Com o MVC tenho controle sobre tudo que está funcionando. Produtividade é > relativa, enquanto o webforms usa e abusa dos componentes que rodam no > server, o MVC abusa do jQuery (e eu fico com o jQuery ... hehehe). Há > plugins para jQuery em tudo que é canto de tudo que é tipo e para tudo que é > funcionalidade ... e é apenas um js (normalmente pequeno) que pode inclusive > ser aberto e retirado o que não será útil para ter melhor performance !!!
> Arrastar um TextBox e soltar na tela ou escrever um Html.TextBox não tem > muita diferença !! (apesar de podermos arrastar controles Html no MVC também > !!!)
> Analisar produtividade é para quem conhece realmente a fundo as duas > tecnologias !!! > Com certeza código limpo é possível obter com as duas tecnologias, porém > talvez não com a mesma facilidade. Enquanto uma é nativamente mais "suja", a > outra é nativamente mais "limpa" ... mas ambas podem ser "sujas" ou > "limpas", depende de quem usa !!
>> Assim como vc nao aceita o argumento que Webforms sao mais produtivos, >>> discordo completamente da sua posicao: "Dizer que MVC não é produtivo é >>> uma grande mentira! E se sua equipe só é produtiva com webforms, então há >>> algo errado."
>>> Trabalho há bastante tempo com webforms e estou comecando agora com MVC e >>> na minha opiniao até o momento Webforms é sim muito mais produtivo do que >>> MVC, pode ser que com o tempo me acostume com o MVC e consiga uma boa >>> produtividade, mas a curva de aprendizado existe, entao pode nao ser algo >>> errado com a equipe.
>>> Não digo que o MVC nao eh produtivo, mas ate o momento posso afirmar que >>> em produtividade ele perde para o Webforms, mas estou procurando estudar e >>> enteder cada vez mais o MVC para ter certeza das suas qualidades e tentar >>> atingir uma melhor produtividade, por isso estou utilizando em alguns >>> projetos.
>>>> Trabalho com webforms há uns 3 anos, é um pouco menos de tempo que tenho >>>> de desenvolvimento (yeah, I'm young).
>>>> Dizer que MVC não é produtivo é uma grande mentira! E se sua equipe só é >>>> produtiva com webforms, então há algo errado.
>>>> Trabalhei em projetos PHP(usando CodeIgniter como framework MVC) e Rails >>>> por exemplo, sem nenhum tipo de controle drag'n'drop, muito menos IDE, e os >>>> projetos foram feitos, entregues, dentro do prazo, com satisfação, etc.
>>>> Alguns dizem "No meu sistema não é preciso ter performance e nem validar >>>> no W3C, etc". Se você entrega um sistema lento, sem padrões, isso é um >>>> problema seu e do seu cliente, não chame isso de produtividade!
>>>> Eu não execro os webforms, mas não aceito o argumento de que são mais >>>> produtivos por que possuem suporte da IDE e controles drag'n'drop.
>>>> 2010/1/25 Juan Pedro A. Lopes <zerova...@gmail.com>
>>>> Eu também estou envolvido com programação há mais de 10 anos e, assim >>>>> como você, sempre preferi trabalhar com o back-end da aplicação, em vez de >>>>> ficar às voltas com UI. Entretanto, não tem como guiar equipes sem conhecer >>>>> as tecnologias nas quais elas trabalham a fundo. Trabalhei com WebForms >>>>> intensivamente por 6 meses. Foi o suficiente para odiá-lo do fundo do meu >>>>> coração. Posso estar sendo extremista, mas qualquer pessoa que se importe >>>>> com a elegância de um código se incomoda com o a desorganização que ficam as >>>>> páginas ASPX. Ainda mais vendo o HTML que elas geram.
>>>>> WebForms só é fácil se você confia 100% no Visual Studio. E mesmo assim >>>>> ele te amarra de uma forma inacreditável.
>>>>> O ASP.NET MVC ainda está meio verde, mas ele se propõe a se parecer >>>>> com o ActionPack do Rails. Se você não conhece, recomendo que estude sobre >>>>> ele. A idela é genial.
>>>>> Todo mundo aqui na empresa teve um momento de dizer o mesmo que você: >>>>> "por que eu vou abandonar tudo o que o WebForms me trouxe (controles, >>>>> patterns, etc.) para trabalhar com HTML?". Eu nunca consegui convencer >>>>> ninguém sem mostrar código. Por isso realizamos diversos Coding Dojos aqui >>>>> na empresa para mostrar como e porque o ASP.NET MVC came to kick >>>>> WebForms' ass out. É simplesmente fantástico.
>>>>> Entretanto, o único conselho que eu dou pra qualquer pessoa que entre >>>>> no ASP.NET MVC é o mesmo que dou para quem aprende Rails ou Karate: >>>>> entenda o porquê das coisas antes de criticá-las. Talvez uma solução não lhe >>>>> pareça a mais elegante a princípio (como a questão de CoC com os >>>>> ModelBinders), mas talvez exista um motivo para ela estar lá.
>>>>> Em linhas gerais, e com um argumento extremamente falacioso, eu digo >>>>> que ASP.NET MVC rocks porque ele me fez gostar de desenvolver >>>>> interfaces. Talvez você também se sinta assim, se pesquisar mais.
>>>>> 2010/1/25 Henrique Jacob <analista....@gmail.com>
>>>>>> Olá!
>>>>>> Não sei se é off, mas vms lá!
>>>>>> Seguinte.. já trabalho com programação tem uns 10 anos... antes >>>>>> disso brincava de "programar" HTML na época em que o Jornal do Brasil era o >>>>>> primeiro jornal na internet e as pessoas faziam coleção de CDs da AOL.
>>>>>> Há um bom tempo. Bom mesmo, não preciso programar interfaces com o >>>>>> usuário fico responsável por fazer as camadas internas ou montando serviços >>>>>> para serem consumidos, etc...
>>>>>> De um ano pra cá, fiquei mais próximo da interface, mas mesmo >>>>>> assim não tive que meter a mão na massa. Mas hj estou em um projeto em que >>>>>> estou usando webform tradicional com MS.AJAX e não estou tendo problemas, >>>>>> como é um sistema de uso interno e na demanda de alta performance de UI e >>>>>> nem telas escalafobéticas... Achei uma opção interessante...
>>>>>> Mas pq estou falando tudo isso??? Bem, nos primórdios de minha vida >>>>>> profissional onde comecei com DELPHI e depois fiquei um tempo com o CENTURA >>>>>> (SQLWindows) fui apresentado ao ASP e o seu VB Script.
>>>>>> Apesar de tudo (VB Script), descobri que gostava de programar pra >>>>>> WEB e fiz grandes sistemas em ASP. Inclusive um CMS Multilíngüe que acaba de >>>>>> completar 8 anos de produção sem cair que atende muito bem o propósito para >>>>>> que foi feito.
>>>>>> Me lembro que os maiores problemas daquela época era a respeito de >>>>>> como tratar a UI... e como dava trabalho programar javascript que >>>>>> funcionasse em todos os browsers e resoluções, manter o estado entre >>>>>> páginas, etc....
>>>>>> Aí surgiu o ASP.NET 1.0 e como em um comercial >>>>>> das organizações Tabajara esta tecnologia veio para resolver todos os nossos >>>>>> problemas técnicos... aos poucos migrei para o .NET e fiz outros tantos >>>>>> sistemas. Alguns um grande sucesso outros e outros apenas sistemas....
>>>>>> Continuei o meu caminho e cada vez mais me afastei da UI... Então >>>>>> esse ano em um grande projeto, a decisão do arquiteto foi usar o >>>>>> ASP.NET MVC e por sorte minha não fiquei responsável pela UI... E vi >>>>>> como um amigo sofreu pra (ele não programou pra "WEB 1.0") garantir >>>>>> Javascript em todos os browsers (ele usou jquery). E uma coisa que não via >>>>>> a anos, ele programou no HTML mesmo não sendo negócio.
>>>>>> Aí pensei.... estamos voltando ao início de tudo?
>>>>>> Mas como não tinha "mexer" com o problema e tinha outras partes do >>>>>> sistema pra construir não me preocupei com isso...
>>>>>> Mas agora estou em um projeto em que preciso decidir entre o >>>>>> tradicional e o novo (velho).
>>>>>> Que opções tenho pra um webforms mais "digno" sem usar o ASP.NETMVC? Ou pq o >>>>>> ASP.NET MVC é tão bom? Pq me dá o HTML na mão? Isso é bom realmente? >>>>>> ou os que estão usando não o tiveram na mão no passado para que pudesse >>>>>> comparar com o presente?
>>>>>> Por favor não me crucifiquem, não sou o anti-cristo. Só quero >>>>>> entender o pq algo que tínhamos no passado e que as pessoas e o mercado >>>>>> festejaram quando tiveram a possibilidade se livrar deste controle, agora
Se produtividade fosse fácil de medir, Gerentes de Projeto e lideres de equipe não ficariam loucos tentando acertar números para cronogramas e não haveria mais erros de cronograma .. seria tudo no prazo !!
A maior parte dos atrasos está diretamente ligado a produtividade porque se avalia a equipe e não os indivíduos .. se há uma pessoa que é menos produtiva usando a tecnologia escolhida, isso precisa ser levado em conta.
Então, como é que pode-se avaliar que uma ou outra é melhor ou mais rápida ???
Eu sei de mim .. eu produzo mais com o MVC que com o webforms, mas isso é por profissional e não por tecnologia !!!
> Concordo contigo Ricardo, e diria ainda que produtividade não pode apennas > ser medida no "tempo de desenvolvimento de determinada feature". > Produtividade se mede no dia-a-dia, no decorrer do projeto, e > principlamente, NA MODIFICAÇÃO DO PROJETO.
> Pra mim produtividade não é disparar um cronômetro e ver quem desenha um > grid primeiro.
> Pode-se comparar produtividade quando se tem domínio nas tecnologias !!!
>> Dizer que webforms é mais produtivo do que o Asp.Net MVC sem conhecer o >> mvc bem, é um equívoco, e vice-versa !!
>> Eu, pessoalmente, gosto muito do MVC. Tenho um controle muito bom sobre >> tudo e tudo funciona bem para minhas necessidades. Nunca gostei do arrastar >> e soltar .... o não saber o que será gerado ou o funcionamento sempre me >> "assustou".
>> Com o MVC tenho controle sobre tudo que está funcionando. Produtividade é >> relativa, enquanto o webforms usa e abusa dos componentes que rodam no >> server, o MVC abusa do jQuery (e eu fico com o jQuery ... hehehe). Há >> plugins para jQuery em tudo que é canto de tudo que é tipo e para tudo que é >> funcionalidade ... e é apenas um js (normalmente pequeno) que pode inclusive >> ser aberto e retirado o que não será útil para ter melhor performance !!!
>> Arrastar um TextBox e soltar na tela ou escrever um Html.TextBox não tem >> muita diferença !! (apesar de podermos arrastar controles Html no MVC também >> !!!)
>> Analisar produtividade é para quem conhece realmente a fundo as duas >> tecnologias !!! >> Com certeza código limpo é possível obter com as duas tecnologias, porém >> talvez não com a mesma facilidade. Enquanto uma é nativamente mais "suja", a >> outra é nativamente mais "limpa" ... mas ambas podem ser "sujas" ou >> "limpas", depende de quem usa !!
>> []'s
>> Ricardo José Alves da Rocha >> Porto Alegre - RS
>>> 2010/1/25 Felipe Borges <felipeu...@gmail.com>
>>> Assim como vc nao aceita o argumento que Webforms sao mais produtivos, >>>> discordo completamente da sua posicao: "Dizer que MVC não é produtivo é >>>> uma grande mentira! E se sua equipe só é produtiva com webforms, então há >>>> algo errado."
>>>> Trabalho há bastante tempo com webforms e estou comecando agora com MVC >>>> e na minha opiniao até o momento Webforms é sim muito mais produtivo do que >>>> MVC, pode ser que com o tempo me acostume com o MVC e consiga uma boa >>>> produtividade, mas a curva de aprendizado existe, entao pode nao ser algo >>>> errado com a equipe.
>>>> Não digo que o MVC nao eh produtivo, mas ate o momento posso afirmar que >>>> em produtividade ele perde para o Webforms, mas estou procurando estudar e >>>> enteder cada vez mais o MVC para ter certeza das suas qualidades e tentar >>>> atingir uma melhor produtividade, por isso estou utilizando em alguns >>>> projetos.
>>>>> Trabalho com webforms há uns 3 anos, é um pouco menos de tempo que >>>>> tenho de desenvolvimento (yeah, I'm young).
>>>>> Dizer que MVC não é produtivo é uma grande mentira! E se sua equipe só >>>>> é produtiva com webforms, então há algo errado.
>>>>> Trabalhei em projetos PHP(usando CodeIgniter como framework MVC) e >>>>> Rails por exemplo, sem nenhum tipo de controle drag'n'drop, muito menos IDE, >>>>> e os projetos foram feitos, entregues, dentro do prazo, com satisfação, etc.
>>>>> Alguns dizem "No meu sistema não é preciso ter performance e nem >>>>> validar no W3C, etc". Se você entrega um sistema lento, sem padrões, isso é >>>>> um problema seu e do seu cliente, não chame isso de produtividade!
>>>>> Eu não execro os webforms, mas não aceito o argumento de que são mais >>>>> produtivos por que possuem suporte da IDE e controles drag'n'drop.
>>>>> 2010/1/25 Juan Pedro A. Lopes <zerova...@gmail.com>
>>>>> Eu também estou envolvido com programação há mais de 10 anos e, assim >>>>>> como você, sempre preferi trabalhar com o back-end da aplicação, em vez de >>>>>> ficar às voltas com UI. Entretanto, não tem como guiar equipes sem conhecer >>>>>> as tecnologias nas quais elas trabalham a fundo. Trabalhei com WebForms >>>>>> intensivamente por 6 meses. Foi o suficiente para odiá-lo do fundo do meu >>>>>> coração. Posso estar sendo extremista, mas qualquer pessoa que se importe >>>>>> com a elegância de um código se incomoda com o a desorganização que ficam as >>>>>> páginas ASPX. Ainda mais vendo o HTML que elas geram.
>>>>>> WebForms só é fácil se você confia 100% no Visual Studio. E mesmo >>>>>> assim ele te amarra de uma forma inacreditável.
>>>>>> O ASP.NET MVC ainda está meio verde, mas ele se propõe a se parecer >>>>>> com o ActionPack do Rails. Se você não conhece, recomendo que estude sobre >>>>>> ele. A idela é genial.
>>>>>> Todo mundo aqui na empresa teve um momento de dizer o mesmo que você: >>>>>> "por que eu vou abandonar tudo o que o WebForms me trouxe (controles, >>>>>> patterns, etc.) para trabalhar com HTML?". Eu nunca consegui convencer >>>>>> ninguém sem mostrar código. Por isso realizamos diversos Coding Dojos aqui >>>>>> na empresa para mostrar como e porque o ASP.NET MVC came to kick >>>>>> WebForms' ass out. É simplesmente fantástico.
>>>>>> Entretanto, o único conselho que eu dou pra qualquer pessoa que entre >>>>>> no ASP.NET MVC é o mesmo que dou para quem aprende Rails ou Karate: >>>>>> entenda o porquê das coisas antes de criticá-las. Talvez uma solução não lhe >>>>>> pareça a mais elegante a princípio (como a questão de CoC com os >>>>>> ModelBinders), mas talvez exista um motivo para ela estar lá.
>>>>>> Em linhas gerais, e com um argumento extremamente falacioso, eu digo >>>>>> que ASP.NET MVC rocks porque ele me fez gostar de desenvolver >>>>>> interfaces. Talvez você também se sinta assim, se pesquisar mais.
>>>>>> 2010/1/25 Henrique Jacob <analista....@gmail.com>
>>>>>>> Olá!
>>>>>>> Não sei se é off, mas vms lá!
>>>>>>> Seguinte.. já trabalho com programação tem uns 10 anos... antes >>>>>>> disso brincava de "programar" HTML na época em que o Jornal do Brasil era o >>>>>>> primeiro jornal na internet e as pessoas faziam coleção de CDs da AOL.
>>>>>>> Há um bom tempo. Bom mesmo, não preciso programar interfaces com o >>>>>>> usuário fico responsável por fazer as camadas internas ou montando serviços >>>>>>> para serem consumidos, etc...
>>>>>>> De um ano pra cá, fiquei mais próximo da interface, mas mesmo >>>>>>> assim não tive que meter a mão na massa. Mas hj estou em um projeto em que >>>>>>> estou usando webform tradicional com MS.AJAX e não estou tendo problemas, >>>>>>> como é um sistema de uso interno e na demanda de alta performance de UI e >>>>>>> nem telas escalafobéticas... Achei uma opção interessante...
>>>>>>> Mas pq estou falando tudo isso??? Bem, nos primórdios de minha vida >>>>>>> profissional onde comecei com DELPHI e depois fiquei um tempo com o CENTURA >>>>>>> (SQLWindows) fui apresentado ao ASP e o seu VB Script.
>>>>>>> Apesar de tudo (VB Script), descobri que gostava de programar pra >>>>>>> WEB e fiz grandes sistemas em ASP. Inclusive um CMS Multilíngüe que acaba de >>>>>>> completar 8 anos de produção sem cair que atende muito bem o propósito para >>>>>>> que foi feito.
>>>>>>> Me lembro que os maiores problemas daquela época era a respeito de >>>>>>> como tratar a UI... e como dava trabalho programar javascript que >>>>>>> funcionasse em todos os browsers e resoluções, manter o estado entre >>>>>>> páginas, etc....
>>>>>>> Aí surgiu o ASP.NET 1.0 e como em um comercial >>>>>>> das organizações Tabajara esta tecnologia veio para resolver todos os nossos >>>>>>> problemas técnicos... aos poucos migrei para o .NET e fiz outros tantos >>>>>>> sistemas. Alguns um grande sucesso outros e outros apenas sistemas....
>>>>>>> Continuei o meu caminho e cada vez mais me afastei da UI... Então >>>>>>> esse ano em um grande projeto, a decisão do arquiteto foi usar o >>>>>>> ASP.NET MVC e por sorte minha não fiquei responsável pela UI... E vi >>>>>>> como um amigo sofreu pra (ele não programou pra "WEB 1.0") garantir >>>>>>> Javascript em todos os
Concordo com o comentário que diz que podemos ter implementações limpas nas duas tecnologias, que isso depende de quem está usando...
Mas o que quero entender é o seguinte... PQ é melhor usar o .NET MVC e não o WebForms... é melhor pq tenho controle de tudo? pq posso usar e abusar de Jquery? é esse o motivo?
Se é pq temos o poder nas mãos, quero entender pq o rejeitamos no início da década?
Não quero causar polêmicas... Não quero saber quem cospe mais longe... Não tenho mais idade... Gostaria de uma análise como a feita por nosso amigo no blog http://sourcerule.wordpress.com/, pensar. Acho que é esse o termo. Desculpem até agora não vi nenhum comentário sobre o WF e o .NET MVC que não seja uma "copia" do que dizem.... Infelizmente, acho eu, que estamos rodeados de tanta informação que perdemos a aptidão de pensar de forma analítica e própria...
Quem conhece a música do Zé Ramalho Vida de GADO.... As vezes vejo isso.. Só mais do mesmo, tal qual os EMOS (nada contra) mas todos iguais... Cadê a identidade própria (me incluo no contexto)...
On 25 jan, 14:05, Ricardo Rocha <ricardorocha....@gmail.com> wrote:
> Pode-se comparar produtividade quando se tem domínio nas tecnologias !!!
> Dizer que webforms é mais produtivo do que o Asp.Net MVC sem conhecer o mvc > bem, é um equívoco, e vice-versa !!
> Eu, pessoalmente, gosto muito do MVC. Tenho um controle muito bom sobre tudo > e tudo funciona bem para minhas necessidades. Nunca gostei do arrastar e > soltar .... o não saber o que será gerado ou o funcionamento sempre me > "assustou".
> Com o MVC tenho controle sobre tudo que está funcionando. Produtividade é > relativa, enquanto o webforms usa e abusa dos componentes que rodam no > server, o MVC abusa do jQuery (e eu fico com o jQuery ... hehehe). Há > plugins para jQuery em tudo que é canto de tudo que é tipo e para tudo que é > funcionalidade ... e é apenas um js (normalmente pequeno) que pode inclusive > ser aberto e retirado o que não será útil para ter melhor performance !!!
> Arrastar um TextBox e soltar na tela ou escrever um Html.TextBox não tem > muita diferença !! (apesar de podermos arrastar controles Html no MVC também > !!!)
> Analisar produtividade é para quem conhece realmente a fundo as duas > tecnologias !!! > Com certeza código limpo é possível obter com as duas tecnologias, porém > talvez não com a mesma facilidade. Enquanto uma é nativamente mais "suja", a > outra é nativamente mais "limpa" ... mas ambas podem ser "sujas" ou > "limpas", depende de quem usa !!
> > 2010/1/25 Felipe Borges <felipeu...@gmail.com>
> > Assim como vc nao aceita o argumento que Webforms sao mais produtivos, > >> discordo completamente da sua posicao: "Dizer que MVC não é produtivo é > >> uma grande mentira! E se sua equipe só é produtiva com webforms, então há > >> algo errado."
> >> Trabalho há bastante tempo com webforms e estou comecando agora com MVC e > >> na minha opiniao até o momento Webforms é sim muito mais produtivo do que > >> MVC, pode ser que com o tempo me acostume com o MVC e consiga uma boa > >> produtividade, mas a curva de aprendizado existe, entao pode nao ser algo > >> errado com a equipe.
> >> Não digo que o MVC nao eh produtivo, mas ate o momento posso afirmar que > >> em produtividade ele perde para o Webforms, mas estou procurando estudar e > >> enteder cada vez mais o MVC para ter certeza das suas qualidades e tentar > >> atingir uma melhor produtividade, por isso estou utilizando em alguns > >> projetos.
> >>> Trabalho com webforms há uns 3 anos, é um pouco menos de tempo que tenho > >>> de desenvolvimento (yeah, I'm young).
> >>> Dizer que MVC não é produtivo é uma grande mentira! E se sua equipe só é > >>> produtiva com webforms, então há algo errado.
> >>> Trabalhei em projetos PHP(usando CodeIgniter como framework MVC) e Rails > >>> por exemplo, sem nenhum tipo de controle drag'n'drop, muito menos IDE, e os > >>> projetos foram feitos, entregues, dentro do prazo, com satisfação, etc.
> >>> Alguns dizem "No meu sistema não é preciso ter performance e nem validar > >>> no W3C, etc". Se você entrega um sistema lento, sem padrões, isso é um > >>> problema seu e do seu cliente, não chame isso de produtividade!
> >>> Eu não execro os webforms, mas não aceito o argumento de que são mais > >>> produtivos por que possuem suporte da IDE e controles drag'n'drop.
> >>> 2010/1/25 Juan Pedro A. Lopes <zerova...@gmail.com>
> >>> Eu também estou envolvido com programação há mais de 10 anos e, assim > >>>> como você, sempre preferi trabalhar com o back-end da aplicação, em vez de > >>>> ficar às voltas com UI. Entretanto, não tem como guiar equipes sem conhecer > >>>> as tecnologias nas quais elas trabalham a fundo. Trabalhei com WebForms > >>>> intensivamente por 6 meses. Foi o suficiente para odiá-lo do fundo do meu > >>>> coração. Posso estar sendo extremista, mas qualquer pessoa que se importe > >>>> com a elegância de um código se incomoda com o a desorganização que ficam as > >>>> páginas ASPX. Ainda mais vendo o HTML que elas geram.
> >>>> WebForms só é fácil se você confia 100% no Visual Studio. E mesmo assim > >>>> ele te amarra de uma forma inacreditável.
> >>>> O ASP.NET MVC ainda está meio verde, mas ele se propõe a se parecer com > >>>> o ActionPack do Rails. Se você não conhece, recomendo que estude sobre ele. > >>>> A idela é genial.
> >>>> Todo mundo aqui na empresa teve um momento de dizer o mesmo que você: > >>>> "por que eu vou abandonar tudo o que o WebForms me trouxe (controles, > >>>> patterns, etc.) para trabalhar com HTML?". Eu nunca consegui convencer > >>>> ninguém sem mostrar código. Por isso realizamos diversos Coding Dojos aqui > >>>> na empresa para mostrar como e porque o ASP.NET MVC came to kick > >>>> WebForms' ass out. É simplesmente fantástico.
> >>>> Entretanto, o único conselho que eu dou pra qualquer pessoa que entre no > >>>> ASP.NET MVC é o mesmo que dou para quem aprende Rails ou Karate: > >>>> entenda o porquê das coisas antes de criticá-las. Talvez uma solução não lhe > >>>> pareça a mais elegante a princípio (como a questão de CoC com os > >>>> ModelBinders), mas talvez exista um motivo para ela estar lá.
> >>>> Em linhas gerais, e com um argumento extremamente falacioso, eu digo que > >>>> ASP.NET MVC rocks porque ele me fez gostar de desenvolver interfaces. > >>>> Talvez você também se sinta assim, se pesquisar mais.
> >>>> 2010/1/25 Henrique Jacob <analista....@gmail.com>
> >>>>> Olá!
> >>>>> Não sei se é off, mas vms lá!
> >>>>> Seguinte.. já trabalho com programação tem uns 10 anos... antes > >>>>> disso brincava de "programar" HTML na época em que o Jornal do Brasil era o > >>>>> primeiro jornal na internet e as pessoas faziam coleção de CDs da AOL.
> >>>>> Há um bom tempo. Bom mesmo, não preciso programar interfaces com o > >>>>> usuário fico responsável por fazer as camadas internas ou montando serviços > >>>>> para serem consumidos, etc...
> >>>>> De um ano pra cá, fiquei mais próximo da interface, mas mesmo assim > >>>>> não tive que meter a mão na massa. Mas hj estou em um projeto em que estou > >>>>> usando webform tradicional com MS.AJAX e não estou tendo problemas, como é > >>>>> um sistema de uso interno e na demanda de alta performance de UI e nem telas > >>>>> escalafobéticas... Achei uma opção interessante...
> >>>>> Mas pq estou falando tudo isso??? Bem, nos primórdios de minha vida > >>>>> profissional onde comecei com DELPHI e depois fiquei um tempo com o CENTURA > >>>>> (SQLWindows) fui apresentado ao ASP e o seu VB Script.
> >>>>> Apesar de tudo (VB Script), descobri que gostava de programar pra WEB > >>>>> e fiz grandes sistemas em ASP. Inclusive um CMS Multilíngüe que acaba de > >>>>> completar 8 anos de produção sem cair que atende muito bem o propósito para > >>>>> que foi feito.
> >>>>> Me lembro que os maiores problemas daquela época era a respeito de > >>>>> como tratar a UI... e como dava trabalho programar javascript que > >>>>> funcionasse em todos os browsers e resoluções, manter o estado entre > >>>>> páginas, etc....
> >>>>> Aí surgiu o ASP.NET 1.0 e como em um comercial > >>>>> das organizações Tabajara esta tecnologia veio para resolver todos os nossos > >>>>> problemas técnicos... aos poucos migrei para o .NET e fiz outros tantos > >>>>> sistemas. Alguns um grande sucesso outros e outros apenas sistemas....
> >>>>> Continuei o meu caminho e cada vez mais me afastei da UI... Então > >>>>> esse ano em um grande projeto, a decisão do arquiteto foi usar o > >>>>> ASP.NET MVC e por sorte minha não fiquei responsável pela UI... E vi > >>>>> como um amigo sofreu pra (ele não programou pra "WEB 1.0") garantir > >>>>> Javascript em todos os browsers (ele usou jquery). E uma coisa que não via > >>>>> a anos, ele programou no HTML mesmo não sendo negócio.
> >>>>> Aí pensei.... estamos voltando ao início de tudo?
> >>>>> Mas como não tinha "mexer" com o problema e tinha outras partes do > >>>>> sistema pra construir não
Asp.Net MVC é melhor não só porque oferece controle sobre o código gerado.
Ele é melhor devido ao padrao MVC. Eu sempre gostei deste padrão e procurei aplicar ele nas coisas que desenvolvi ao longo do tempo. Cada parte tem sua responsabilidadee vc sabe qual é. Se respeitar o padrão vc não precisará se preocupar de onde está tal coisa ... basta pensar se ele é de responsabilidade da Model, da View ou do Controller e olhar ... fácil assim.
Como disse antes, webforms oferece muitas coisas e vc pode desenvolver usando padrões como o próprio MVC, mas vc acha que terá a mesma facilidade nisso?
Se vc quer fazer um rali, vai pegar um carro preparado para o deserto ou um desenvolvido para andar na cidade ???
Entende? Não é questão de ser melhor ou pior e sim de contexto !!
Se não quer o padrão MVC pode usar o webforms na boa ... Se gosta deste padrão e dos controles que esta escolha te traz, fique com o MVC, que foi criado para trabalhar desta forma.
Controle sobre o código e código limpo são consequências e dependem mais do desenvolvedor do que da tecnologia. No MVC abusamos do jQuery e fazemos requisições via Ajax ... no webforms usa-se os controles Ajax .. qual a diferença real ??? Ambos são JavaScript fazendo requisições no servidor !! Em ambos casos tem como atualizar a UI sem recarregar toda página, etc ...
Então, escolha de acordo com o padrão de desenvolvimento que te agrada. Conheço pessoas que não abandonam o webforms por nada e pessoas que dão a vida pelo mvc ... hehehe. Questão de gosto, como sempre !!
> Concordo com o comentário que diz que podemos ter implementações > limpas nas duas tecnologias, que isso depende de quem está usando...
> Mas o que quero entender é o seguinte... PQ é melhor usar o .NET MVC > e não o WebForms... é melhor pq tenho controle de tudo? pq posso usar > e abusar de Jquery? é esse o motivo?
> Se é pq temos o poder nas mãos, quero entender pq o rejeitamos no > início da década?
> Não quero causar polêmicas... Não quero saber quem cospe mais > longe... Não tenho mais idade... Gostaria de uma análise como a feita > por nosso amigo no blog http://sourcerule.wordpress.com/, pensar. Acho > que é esse o termo. Desculpem até agora não vi nenhum comentário sobre > o WF e o .NET MVC que não seja uma "copia" do que dizem.... > Infelizmente, acho eu, que estamos rodeados de tanta informação que > perdemos a aptidão de pensar de forma analítica e própria...
> Quem conhece a música do Zé Ramalho Vida de GADO.... As vezes vejo > isso.. Só mais do mesmo, tal qual os EMOS (nada contra) mas todos > iguais... Cadê a identidade própria (me incluo no contexto)...
> On 25 jan, 14:05, Ricardo Rocha <ricardorocha....@gmail.com> wrote: > > Pode-se comparar produtividade quando se tem domínio nas tecnologias !!!
> > Dizer que webforms é mais produtivo do que o Asp.Net MVC sem conhecer o > mvc > > bem, é um equívoco, e vice-versa !!
> > Eu, pessoalmente, gosto muito do MVC. Tenho um controle muito bom sobre > tudo > > e tudo funciona bem para minhas necessidades. Nunca gostei do arrastar e > > soltar .... o não saber o que será gerado ou o funcionamento sempre me > > "assustou".
> > Com o MVC tenho controle sobre tudo que está funcionando. Produtividade é > > relativa, enquanto o webforms usa e abusa dos componentes que rodam no > > server, o MVC abusa do jQuery (e eu fico com o jQuery ... hehehe). Há > > plugins para jQuery em tudo que é canto de tudo que é tipo e para tudo > que é > > funcionalidade ... e é apenas um js (normalmente pequeno) que pode > inclusive > > ser aberto e retirado o que não será útil para ter melhor performance !!!
> > Arrastar um TextBox e soltar na tela ou escrever um Html.TextBox não tem > > muita diferença !! (apesar de podermos arrastar controles Html no MVC > também > > !!!)
> > Analisar produtividade é para quem conhece realmente a fundo as duas > > tecnologias !!! > > Com certeza código limpo é possível obter com as duas tecnologias, porém > > talvez não com a mesma facilidade. Enquanto uma é nativamente mais > "suja", a > > outra é nativamente mais "limpa" ... mas ambas podem ser "sujas" ou > > "limpas", depende de quem usa !!
> > []'s
> > Ricardo José Alves da Rocha > > Porto Alegre - RS
> > > 2010/1/25 Felipe Borges <felipeu...@gmail.com>
> > > Assim como vc nao aceita o argumento que Webforms sao mais produtivos, > > >> discordo completamente da sua posicao: "Dizer que MVC não é produtivo > é > > >> uma grande mentira! E se sua equipe só é produtiva com webforms, então > há > > >> algo errado."
> > >> Trabalho há bastante tempo com webforms e estou comecando agora com > MVC e > > >> na minha opiniao até o momento Webforms é sim muito mais produtivo do > que > > >> MVC, pode ser que com o tempo me acostume com o MVC e consiga uma boa > > >> produtividade, mas a curva de aprendizado existe, entao pode nao ser > algo > > >> errado com a equipe.
> > >> Não digo que o MVC nao eh produtivo, mas ate o momento posso afirmar > que > > >> em produtividade ele perde para o Webforms, mas estou procurando > estudar e > > >> enteder cada vez mais o MVC para ter certeza das suas qualidades e > tentar > > >> atingir uma melhor produtividade, por isso estou utilizando em alguns > > >> projetos.
> > >>> Trabalho com webforms há uns 3 anos, é um pouco menos de tempo que > tenho > > >>> de desenvolvimento (yeah, I'm young).
> > >>> Dizer que MVC não é produtivo é uma grande mentira! E se sua equipe > só é > > >>> produtiva com webforms, então há algo errado.
> > >>> Trabalhei em projetos PHP(usando CodeIgniter como framework MVC) e > Rails > > >>> por exemplo, sem nenhum tipo de controle drag'n'drop, muito menos > IDE, e os > > >>> projetos foram feitos, entregues, dentro do prazo, com satisfação, > etc.
> > >>> Alguns dizem "No meu sistema não é preciso ter performance e nem > validar > > >>> no W3C, etc". Se você entrega um sistema lento, sem padrões, isso é > um > > >>> problema seu e do seu cliente, não chame isso de produtividade!
> > >>> Eu não execro os webforms, mas não aceito o argumento de que são mais > > >>> produtivos por que possuem suporte da IDE e controles drag'n'drop.
> > >>> 2010/1/25 Juan Pedro A. Lopes <zerova...@gmail.com>
> > >>> Eu também estou envolvido com programação há mais de 10 anos e, assim > > >>>> como você, sempre preferi trabalhar com o back-end da aplicação, em > vez de > > >>>> ficar às voltas com UI. Entretanto, não tem como guiar equipes sem > conhecer > > >>>> as tecnologias nas quais elas trabalham a fundo. Trabalhei com > WebForms > > >>>> intensivamente por 6 meses. Foi o suficiente para odiá-lo do fundo > do meu > > >>>> coração. Posso estar sendo extremista, mas qualquer pessoa que se > importe > > >>>> com a elegância de um código se incomoda com o a desorganização que > ficam as > > >>>> páginas ASPX. Ainda mais vendo o HTML que elas geram.
> > >>>> WebForms só é fácil se você confia 100% no Visual Studio. E mesmo > assim > > >>>> ele te amarra de uma forma inacreditável.
> > >>>> O ASP.NET MVC ainda está meio verde, mas ele se propõe a se parecer > com > > >>>> o ActionPack do Rails. Se você não conhece, recomendo que estude > sobre ele. > > >>>> A idela é genial.
> > >>>> Todo mundo aqui na empresa teve um momento de dizer o mesmo que > você: > > >>>> "por que eu vou abandonar tudo o que o WebForms me trouxe > (controles, > > >>>> patterns, etc.) para trabalhar com HTML?". Eu nunca consegui > convencer > > >>>> ninguém sem mostrar código. Por isso realizamos diversos Coding > Dojos aqui > > >>>> na empresa para mostrar como e porque o ASP.NET MVC came to kick > > >>>> WebForms' ass out. É simplesmente fantástico.
> > >>>> Entretanto, o único conselho que eu dou pra qualquer pessoa que > entre no > > >>>> ASP.NET MVC é o mesmo que dou para quem aprende Rails ou Karate: > > >>>> entenda o porquê das coisas antes de criticá-las. Talvez uma solução > não lhe > > >>>> pareça a mais elegante a princípio (como a questão de CoC com os > > >>>> ModelBinders), mas talvez exista um motivo para ela estar lá.
> > >>>> Em linhas gerais, e com um argumento extremamente falacioso, eu digo > que > > >>>> ASP.NET MVC rocks porque ele me fez gostar de desenvolver > interfaces. > > >>>> Talvez você também se sinta assim, se pesquisar mais.
> > >>>> 2010/1/25 Henrique Jacob <analista....@gmail.com>
> > >>>>> Olá!
> > >>>>> Não sei se é off, mas vms lá!
> > >>>>> Seguinte.. já trabalho com programação tem uns 10 anos... > antes > > >>>>> disso brincava de "programar" HTML na época em que o Jornal do > Brasil era o > > >>>>> primeiro jornal na internet e as pessoas faziam coleção de CDs da > AOL.
> > >>>>> Há um bom tempo. Bom mesmo, não preciso programar interfaces com > o > > >>>>> usuário fico responsável por fazer as camadas internas
E no início da década, lá no asp 3 e tals, não podíamos comparar as coisas. Primeiro o .net possui mais de 5k classes e o asp.net hoje possui controles aos montes, e o asp 3 contava basicamente com 4 classes se não me engano, um pouco mais que isso, para fazer todo o trabalho.
O MVC além de te dar o controle sobre o código gerado, implementa claramente um padrão de arquitetura e separação de camadas. Possibilita maior testabilidade pois é simples e fácil testar os controllers, models e services por exemplo, o que é bem difícil com asp.net, talvez impossível, testar unitariamente um code behind de uma página.
Existem diversos posts comparando as duas tecnologias, detalhadamente, com certeza feitos melhores do que eu faria.
O que eu posso, honestamente dizer, é que eu usaria o mvc em todos os cenários, e os webforms eu não usaria em alguns cenários. Cenários estes baseados em testabilidade, simplicidade de código, onde manutenções são constantes, onde interfaces ricas são requeridas, etc.
> Concordo com o comentário que diz que podemos ter implementações > limpas nas duas tecnologias, que isso depende de quem está usando...
> Mas o que quero entender é o seguinte... PQ é melhor usar o .NET MVC > e não o WebForms... é melhor pq tenho controle de tudo? pq posso usar > e abusar de Jquery? é esse o motivo?
> Se é pq temos o poder nas mãos, quero entender pq o rejeitamos no > início da década?
> Não quero causar polêmicas... Não quero saber quem cospe mais > longe... Não tenho mais idade... Gostaria de uma análise como a feita > por nosso amigo no blog http://sourcerule.wordpress.com/, pensar. Acho > que é esse o termo. Desculpem até agora não vi nenhum comentário sobre > o WF e o .NET MVC que não seja uma "copia" do que dizem.... > Infelizmente, acho eu, que estamos rodeados de tanta informação que > perdemos a aptidão de pensar de forma analítica e própria...
> Quem conhece a música do Zé Ramalho Vida de GADO.... As vezes vejo > isso.. Só mais do mesmo, tal qual os EMOS (nada contra) mas todos > iguais... Cadê a identidade própria (me incluo no contexto)...
> On 25 jan, 14:05, Ricardo Rocha <ricardorocha....@gmail.com> wrote: > > Pode-se comparar produtividade quando se tem domínio nas tecnologias !!!
> > Dizer que webforms é mais produtivo do que o Asp.Net MVC sem conhecer o > mvc > > bem, é um equívoco, e vice-versa !!
> > Eu, pessoalmente, gosto muito do MVC. Tenho um controle muito bom sobre > tudo > > e tudo funciona bem para minhas necessidades. Nunca gostei do arrastar e > > soltar .... o não saber o que será gerado ou o funcionamento sempre me > > "assustou".
> > Com o MVC tenho controle sobre tudo que está funcionando. Produtividade é > > relativa, enquanto o webforms usa e abusa dos componentes que rodam no > > server, o MVC abusa do jQuery (e eu fico com o jQuery ... hehehe). Há > > plugins para jQuery em tudo que é canto de tudo que é tipo e para tudo > que é > > funcionalidade ... e é apenas um js (normalmente pequeno) que pode > inclusive > > ser aberto e retirado o que não será útil para ter melhor performance !!!
> > Arrastar um TextBox e soltar na tela ou escrever um Html.TextBox não tem > > muita diferença !! (apesar de podermos arrastar controles Html no MVC > também > > !!!)
> > Analisar produtividade é para quem conhece realmente a fundo as duas > > tecnologias !!! > > Com certeza código limpo é possível obter com as duas tecnologias, porém > > talvez não com a mesma facilidade. Enquanto uma é nativamente mais > "suja", a > > outra é nativamente mais "limpa" ... mas ambas podem ser "sujas" ou > > "limpas", depende de quem usa !!
> > []'s
> > Ricardo José Alves da Rocha > > Porto Alegre - RS
> > > 2010/1/25 Felipe Borges <felipeu...@gmail.com>
> > > Assim como vc nao aceita o argumento que Webforms sao mais produtivos, > > >> discordo completamente da sua posicao: "Dizer que MVC não é produtivo > é > > >> uma grande mentira! E se sua equipe só é produtiva com webforms, então > há > > >> algo errado."
> > >> Trabalho há bastante tempo com webforms e estou comecando agora com > MVC e > > >> na minha opiniao até o momento Webforms é sim muito mais produtivo do > que > > >> MVC, pode ser que com o tempo me acostume com o MVC e consiga uma boa > > >> produtividade, mas a curva de aprendizado existe, entao pode nao ser > algo > > >> errado com a equipe.
> > >> Não digo que o MVC nao eh produtivo, mas ate o momento posso afirmar > que > > >> em produtividade ele perde para o Webforms, mas estou procurando > estudar e > > >> enteder cada vez mais o MVC para ter certeza das suas qualidades e > tentar > > >> atingir uma melhor produtividade, por isso estou utilizando em alguns > > >> projetos.
> > >>> Trabalho com webforms há uns 3 anos, é um pouco menos de tempo que > tenho > > >>> de desenvolvimento (yeah, I'm young).
> > >>> Dizer que MVC não é produtivo é uma grande mentira! E se sua equipe > só é > > >>> produtiva com webforms, então há algo errado.
> > >>> Trabalhei em projetos PHP(usando CodeIgniter como framework MVC) e > Rails > > >>> por exemplo, sem nenhum tipo de controle drag'n'drop, muito menos > IDE, e os > > >>> projetos foram feitos, entregues, dentro do prazo, com satisfação, > etc.
> > >>> Alguns dizem "No meu sistema não é preciso ter performance e nem > validar > > >>> no W3C, etc". Se você entrega um sistema lento, sem padrões, isso é > um > > >>> problema seu e do seu cliente, não chame isso de produtividade!
> > >>> Eu não execro os webforms, mas não aceito o argumento de que são mais > > >>> produtivos por que possuem suporte da IDE e controles drag'n'drop.
> > >>> 2010/1/25 Juan Pedro A. Lopes <zerova...@gmail.com>
> > >>> Eu também estou envolvido com programação há mais de 10 anos e, assim > > >>>> como você, sempre preferi trabalhar com o back-end da aplicação, em > vez de > > >>>> ficar às voltas com UI. Entretanto, não tem como guiar equipes sem > conhecer > > >>>> as tecnologias nas quais elas trabalham a fundo. Trabalhei com > WebForms > > >>>> intensivamente por 6 meses. Foi o suficiente para odiá-lo do fundo > do meu > > >>>> coração. Posso estar sendo extremista, mas qualquer pessoa que se > importe > > >>>> com a elegância de um código se incomoda com o a desorganização que > ficam as > > >>>> páginas ASPX. Ainda mais vendo o HTML que elas geram.
> > >>>> WebForms só é fácil se você confia 100% no Visual Studio. E mesmo > assim > > >>>> ele te amarra de uma forma inacreditável.
> > >>>> O ASP.NET MVC ainda está meio verde, mas ele se propõe a se parecer > com > > >>>> o ActionPack do Rails. Se você não conhece, recomendo que estude > sobre ele. > > >>>> A idela é genial.
> > >>>> Todo mundo aqui na empresa teve um momento de dizer o mesmo que > você: > > >>>> "por que eu vou abandonar tudo o que o WebForms me trouxe > (controles, > > >>>> patterns, etc.) para trabalhar com HTML?". Eu nunca consegui > convencer > > >>>> ninguém sem mostrar código. Por isso realizamos diversos Coding > Dojos aqui > > >>>> na empresa para mostrar como e porque o ASP.NET MVC came to kick > > >>>> WebForms' ass out. É simplesmente fantástico.
> > >>>> Entretanto, o único conselho que eu dou pra qualquer pessoa que > entre no > > >>>> ASP.NET MVC é o mesmo que dou para quem aprende Rails ou Karate: > > >>>> entenda o porquê das coisas antes de criticá-las. Talvez uma solução > não lhe > > >>>> pareça a mais elegante a princípio (como a questão de CoC com os > > >>>> ModelBinders), mas talvez exista um motivo para ela estar lá.
> > >>>> Em linhas gerais, e com um argumento extremamente falacioso, eu digo > que > > >>>> ASP.NET MVC rocks porque ele me fez gostar de desenvolver > interfaces. > > >>>> Talvez você também se sinta assim, se pesquisar mais.
> > >>>> 2010/1/25 Henrique Jacob <analista....@gmail.com>
> > >>>>> Olá!
> > >>>>> Não sei se é off, mas vms lá!
> > >>>>> Seguinte.. já trabalho com programação tem uns 10 anos... > antes > > >>>>> disso brincava de "programar" HTML na época em que o Jornal do > Brasil era o > > >>>>> primeiro jornal na internet e as pessoas faziam coleção de CDs da > AOL.
> > >>>>> Há um bom tempo. Bom mesmo, não preciso programar interfaces com > o > > >>>>> usuário fico responsável por fazer as camadas internas ou montando > serviços > > >>>>> para serem consumidos, etc...
> > >>>>> De um ano pra cá, fiquei mais próximo da interface, mas mesmo > assim > > >>>>> não tive que meter a mão na massa. Mas hj estou em um projeto em > que estou > > >>>>> usando webform tradicional com MS.AJAX e não estou tendo problemas, > como é > > >>>>> um sistema de uso interno e na demanda de alta performance de UI e > nem telas > > >>>>> escalafobéticas... Achei uma opção interessante...
Não são tão extremista como o Juan, mas compartilho a opinião dele de que webforms are evil. Mas acho que não tem nada a ver com produtividade ou elegancia, aliás, pra projetos pequenos é possível ser bem produtivo em webforms.
O que eu acho é que para telas complexas, o webforms gera um código que tende a ser dificil de manter com o tempo. A interação entre os controles, o ciclo de vida do webform, a complicação de viewstate etc., fazem com que as telas fiquem um pesadelo. Eu falo por experiencia propria, nós temos sistemas muito antigos, com páginas feitas em ASP.NET classico, que são simplesmente inviáveis de manter.
Outro ponto que pra mim é fundamental é a capacidade de se "automatizar" determinadas operações, facilitando o uso de frameworks. Com MVC, isto é extremamente fácil de fazer (nós temos a nossa própria viewengine p.ex.)... No web.forms, nós tentamos fazer frameworks por 10 anos, sem sucesso. E isto sim, afeta produtividade (mas é um caso muito particular nosso).
Então, concordo com o que outros falaram. Para um projeto pequeno e que não vá crescer (dificil garantir isto né?), tanto faz, talvez até o webforms tenha um v0 menor. Agora pra projetos de maior porte e se for necessário usar frameworks de interface, eu acho que o MVC é mais adequado. Hoje eu nem concebo iniciar um projeto em webforms.
> Concordo com o comentário que diz que podemos ter implementações > limpas nas duas tecnologias, que isso depende de quem está usando...
> Mas o que quero entender é o seguinte... PQ é melhor usar o .NET MVC > e não o WebForms... é melhor pq tenho controle de tudo? pq posso usar > e abusar de Jquery? é esse o motivo?
> Se é pq temos o poder nas mãos, quero entender pq o rejeitamos no > início da década?
> Não quero causar polêmicas... Não quero saber quem cospe mais > longe... Não tenho mais idade... Gostaria de uma análise como a feita > por nosso amigo no blog http://sourcerule.wordpress.com/, pensar. Acho > que é esse o termo. Desculpem até agora não vi nenhum comentário sobre > o WF e o .NET MVC que não seja uma "copia" do que dizem.... > Infelizmente, acho eu, que estamos rodeados de tanta informação que > perdemos a aptidão de pensar de forma analítica e própria...
> Quem conhece a música do Zé Ramalho Vida de GADO.... As vezes vejo > isso.. Só mais do mesmo, tal qual os EMOS (nada contra) mas todos > iguais... Cadê a identidade própria (me incluo no contexto)...
> On 25 jan, 14:05, Ricardo Rocha <ricardorocha....@gmail.com> wrote: > > Pode-se comparar produtividade quando se tem domínio nas tecnologias !!!
> > Dizer que webforms é mais produtivo do que o Asp.Net MVC sem conhecer o > mvc > > bem, é um equívoco, e vice-versa !!
> > Eu, pessoalmente, gosto muito do MVC. Tenho um controle muito bom sobre > tudo > > e tudo funciona bem para minhas necessidades. Nunca gostei do arrastar e > > soltar .... o não saber o que será gerado ou o funcionamento sempre me > > "assustou".
> > Com o MVC tenho controle sobre tudo que está funcionando. Produtividade é > > relativa, enquanto o webforms usa e abusa dos componentes que rodam no > > server, o MVC abusa do jQuery (e eu fico com o jQuery ... hehehe). Há > > plugins para jQuery em tudo que é canto de tudo que é tipo e para tudo > que é > > funcionalidade ... e é apenas um js (normalmente pequeno) que pode > inclusive > > ser aberto e retirado o que não será útil para ter melhor performance !!!
> > Arrastar um TextBox e soltar na tela ou escrever um Html.TextBox não tem > > muita diferença !! (apesar de podermos arrastar controles Html no MVC > também > > !!!)
> > Analisar produtividade é para quem conhece realmente a fundo as duas > > tecnologias !!! > > Com certeza código limpo é possível obter com as duas tecnologias, porém > > talvez não com a mesma facilidade. Enquanto uma é nativamente mais > "suja", a > > outra é nativamente mais "limpa" ... mas ambas podem ser "sujas" ou > > "limpas", depende de quem usa !!
> > []'s
> > Ricardo José Alves da Rocha > > Porto Alegre - RS
> > > 2010/1/25 Felipe Borges <felipeu...@gmail.com>
> > > Assim como vc nao aceita o argumento que Webforms sao mais produtivos, > > >> discordo completamente da sua posicao: "Dizer que MVC não é produtivo > é > > >> uma grande mentira! E se sua equipe só é produtiva com webforms, então > há > > >> algo errado."
> > >> Trabalho há bastante tempo com webforms e estou comecando agora com > MVC e > > >> na minha opiniao até o momento Webforms é sim muito mais produtivo do > que > > >> MVC, pode ser que com o tempo me acostume com o MVC e consiga uma boa > > >> produtividade, mas a curva de aprendizado existe, entao pode nao ser > algo > > >> errado com a equipe.
> > >> Não digo que o MVC nao eh produtivo, mas ate o momento posso afirmar > que > > >> em produtividade ele perde para o Webforms, mas estou procurando > estudar e > > >> enteder cada vez mais o MVC para ter certeza das suas qualidades e > tentar > > >> atingir uma melhor produtividade, por isso estou utilizando em alguns > > >> projetos.
> > >>> Trabalho com webforms há uns 3 anos, é um pouco menos de tempo que > tenho > > >>> de desenvolvimento (yeah, I'm young).
> > >>> Dizer que MVC não é produtivo é uma grande mentira! E se sua equipe > só é > > >>> produtiva com webforms, então há algo errado.
> > >>> Trabalhei em projetos PHP(usando CodeIgniter como framework MVC) e > Rails > > >>> por exemplo, sem nenhum tipo de controle drag'n'drop, muito menos > IDE, e os > > >>> projetos foram feitos, entregues, dentro do prazo, com satisfação, > etc.
> > >>> Alguns dizem "No meu sistema não é preciso ter performance e nem > validar > > >>> no W3C, etc". Se você entrega um sistema lento, sem padrões, isso é > um > > >>> problema seu e do seu cliente, não chame isso de produtividade!
> > >>> Eu não execro os webforms, mas não aceito o argumento de que são mais > > >>> produtivos por que possuem suporte da IDE e controles drag'n'drop.
> > >>> 2010/1/25 Juan Pedro A. Lopes <zerova...@gmail.com>
> > >>> Eu também estou envolvido com programação há mais de 10 anos e, assim > > >>>> como você, sempre preferi trabalhar com o back-end da aplicação, em > vez de > > >>>> ficar às voltas com UI. Entretanto, não tem como guiar equipes sem > conhecer > > >>>> as tecnologias nas quais elas trabalham a fundo. Trabalhei com > WebForms > > >>>> intensivamente por 6 meses. Foi o suficiente para odiá-lo do fundo > do meu > > >>>> coração. Posso estar sendo extremista, mas qualquer pessoa que se > importe > > >>>> com a elegância de um código se incomoda com o a desorganização que > ficam as > > >>>> páginas ASPX. Ainda mais vendo o HTML que elas geram.
> > >>>> WebForms só é fácil se você confia 100% no Visual Studio. E mesmo > assim > > >>>> ele te amarra de uma forma inacreditável.
> > >>>> O ASP.NET MVC ainda está meio verde, mas ele se propõe a se parecer > com > > >>>> o ActionPack do Rails. Se você não conhece, recomendo que estude > sobre ele. > > >>>> A idela é genial.
> > >>>> Todo mundo aqui na empresa teve um momento de dizer o mesmo que > você: > > >>>> "por que eu vou abandonar tudo o que o WebForms me trouxe > (controles, > > >>>> patterns, etc.) para trabalhar com HTML?". Eu nunca consegui > convencer > > >>>> ninguém sem mostrar código. Por isso realizamos diversos Coding > Dojos aqui > > >>>> na empresa para mostrar como e porque o ASP.NET MVC came to kick > > >>>> WebForms' ass out. É simplesmente fantástico.
> > >>>> Entretanto, o único conselho que eu dou pra qualquer pessoa que > entre no > > >>>> ASP.NET MVC é o mesmo que dou para quem aprende Rails ou Karate: > > >>>> entenda o porquê das coisas antes de criticá-las. Talvez uma solução > não lhe > > >>>> pareça a mais elegante a princípio (como a questão de CoC com os > > >>>> ModelBinders), mas talvez exista um motivo para ela estar lá.
> > >>>> Em linhas gerais, e com um argumento extremamente falacioso, eu digo > que > > >>>> ASP.NET MVC rocks porque ele me fez gostar de desenvolver > interfaces. > > >>>> Talvez você também se sinta assim, se pesquisar mais.
> > >>>> 2010/1/25 Henrique Jacob <analista....@gmail.com>
> > >>>>> Olá!
> > >>>>> Não sei se é off, mas vms lá!
> > >>>>> Seguinte.. já trabalho com programação tem uns 10 anos... > antes > > >>>>> disso brincava de "programar" HTML na época em que o Jornal do > Brasil era o > > >>>>> primeiro jornal na internet e as pessoas faziam coleção de CDs da > AOL.
> > >>>>> Há um bom tempo. Bom mesmo, não preciso programar interfaces com > o > > >>>>> usuário fico responsável por fazer as camadas internas ou montando > serviços > > >>>>> para serem consumidos, etc...
> > >>>>> De um ano pra cá, fiquei mais próximo da interface, mas mesmo > assim > > >>>>> não tive que meter a mão na massa. Mas hj estou em um
sinto com se estivesse "loop" as discussões são basicamente as mesmas: Modelo Rico X Modelo Anemico; Asp.Net WebForms X Asp.Net MVC; Metodos Ageis x Não Ageis; VB.Net X C#; TDD x Não TDD; Dot.Net x O resto das tecnologias de desenvolvimento de Software. E por ai vai......
As tecnologias/metodologias estão ai para "todos os gostos", todas elas tem seus prós e contras. Cabe a nós, que somos profissionais da àrea, conhece-las o suficiente para poder aplicar nos cenários onde aquela tecnologia/metodologia melhor atender aos requisitos. Toda nova tecnologia/metodologia lançada promete mil e uma vantagens sobre as anteriores, que sempre terá alguma vantagem, eu não discordo. Porém, analisando profundamente todas também tem suas desvantagens.
As vezes parace que esquecemos que estamos fazendo software para outras pessoas usarem. O que o usuario final do sistema quer é um sistema simples de utilizar e que atenda plenamente as requisitos que foram solicitados. Se o html esta "feio" o usuario final não vai nem saber, mas se ao inves de um simples click num checkBox ele tiver que clicar em um monte de links e ficar pulando de página em página para conseguir juntar a informação que ele necessita, pode ter certeza que, neste momento, a mãe de quem fez o software é lembrada e não de uma maneira boa.
Tenho visto mutsas promessas de código facil de fazer, manter, e extender. Promessas de sistemas bug-free, de sistemas que serão entregues com sucesso total, de que se o sistema for muito complexo, será mais facil de fazer, etc, etc.
Eu tenho muita fé que todas estas promessas são verdadeiras, por isso tenho estudado esta montanha de sopa de letras que temos a disposição, ainda não estou convencido de que todas as promessas são verdadeiras, mas TENHO FÉ!!
Isso tudo IMHO!
[]´s
Edmilson
___________________________________________________________________________ _________ Veja quais são os assuntos do momento no Yahoo! +Buscados http://br.maisbuscados.yahoo.com
Só uma pequena observacao, sobre essa colocação do Ricardo Rocha: "MVC abusa do jQuery (e eu fico com o jQuery ... hehehe). Há plugins para jQuery em tudo que é canto de tudo que é tipo e para tudo que é funcionalidade ... e é apenas um js (normalmente pequeno) que pode inclusive ser aberto e retirado o que não será útil para ter melhor performance !!!"
Sera que os desenvolvedores que usam MVC procuram entender estes JS/!?!?? Duvido que mtos deles param pra analisar o q esta dentro destes plugins... simplesmente pegam um tutorial de como inseri-los na pagina e seguem usando... ou seja, nao seria similar ao arrastar e soltar do webforms?!? Poluir a tela com javascript dos controles que acessam o server seria pior do que os javascripts do Jquery?!? Nao quero polemizar, como disse estou comecando com MVC, soh estou interessado em saber das diferencas...
> Não são tão extremista como o Juan, mas compartilho a opinião dele de que > webforms are evil. Mas acho que não tem nada a ver com produtividade ou > elegancia, aliás, pra projetos pequenos é possível ser bem produtivo em > webforms.
> O que eu acho é que para telas complexas, o webforms gera um código que > tende a ser dificil de manter com o tempo. A interação entre os controles, o > ciclo de vida do webform, a complicação de viewstate etc., fazem com que as > telas fiquem um pesadelo. Eu falo por experiencia propria, nós temos > sistemas muito antigos, com páginas feitas em ASP.NET classico, que são > simplesmente inviáveis de manter.
> Outro ponto que pra mim é fundamental é a capacidade de se "automatizar" > determinadas operações, facilitando o uso de frameworks. Com MVC, isto é > extremamente fácil de fazer (nós temos a nossa própria viewengine p.ex.)... > No web.forms, nós tentamos fazer frameworks por 10 anos, sem sucesso. E isto > sim, afeta produtividade (mas é um caso muito particular nosso).
> Então, concordo com o que outros falaram. Para um projeto pequeno e que não > vá crescer (dificil garantir isto né?), tanto faz, talvez até o webforms > tenha um v0 menor. Agora pra projetos de maior porte e se for necessário > usar frameworks de interface, eu acho que o MVC é mais adequado. Hoje eu nem > concebo iniciar um projeto em webforms.
> 2010/1/25 Henrique Jacob <analista....@gmail.com>
> Vms lá pessoal!
>> Não precisamos brigar....
>> Concordo com o comentário que diz que podemos ter implementações >> limpas nas duas tecnologias, que isso depende de quem está usando...
>> Mas o que quero entender é o seguinte... PQ é melhor usar o .NET MVC >> e não o WebForms... é melhor pq tenho controle de tudo? pq posso usar >> e abusar de Jquery? é esse o motivo?
>> Se é pq temos o poder nas mãos, quero entender pq o rejeitamos no >> início da década?
>> Não quero causar polêmicas... Não quero saber quem cospe mais >> longe... Não tenho mais idade... Gostaria de uma análise como a feita >> por nosso amigo no blog http://sourcerule.wordpress.com/, pensar. Acho >> que é esse o termo. Desculpem até agora não vi nenhum comentário sobre >> o WF e o .NET MVC que não seja uma "copia" do que dizem.... >> Infelizmente, acho eu, que estamos rodeados de tanta informação que >> perdemos a aptidão de pensar de forma analítica e própria...
>> Quem conhece a música do Zé Ramalho Vida de GADO.... As vezes vejo >> isso.. Só mais do mesmo, tal qual os EMOS (nada contra) mas todos >> iguais... Cadê a identidade própria (me incluo no contexto)...
>> On 25 jan, 14:05, Ricardo Rocha <ricardorocha....@gmail.com> wrote: >> > Pode-se comparar produtividade quando se tem domínio nas tecnologias !!!
>> > Dizer que webforms é mais produtivo do que o Asp.Net MVC sem conhecer o >> mvc >> > bem, é um equívoco, e vice-versa !!
>> > Eu, pessoalmente, gosto muito do MVC. Tenho um controle muito bom sobre >> tudo >> > e tudo funciona bem para minhas necessidades. Nunca gostei do arrastar e >> > soltar .... o não saber o que será gerado ou o funcionamento sempre me >> > "assustou".
>> > Com o MVC tenho controle sobre tudo que está funcionando. Produtividade >> é >> > relativa, enquanto o webforms usa e abusa dos componentes que rodam no >> > server, o MVC abusa do jQuery (e eu fico com o jQuery ... hehehe). Há >> > plugins para jQuery em tudo que é canto de tudo que é tipo e para tudo >> que é >> > funcionalidade ... e é apenas um js (normalmente pequeno) que pode >> inclusive >> > ser aberto e retirado o que não será útil para ter melhor performance >> !!!
>> > Arrastar um TextBox e soltar na tela ou escrever um Html.TextBox não tem >> > muita diferença !! (apesar de podermos arrastar controles Html no MVC >> também >> > !!!)
>> > Analisar produtividade é para quem conhece realmente a fundo as duas >> > tecnologias !!! >> > Com certeza código limpo é possível obter com as duas tecnologias, porém >> > talvez não com a mesma facilidade. Enquanto uma é nativamente mais >> "suja", a >> > outra é nativamente mais "limpa" ... mas ambas podem ser "sujas" ou >> > "limpas", depende de quem usa !!
>> > []'s
>> > Ricardo José Alves da Rocha >> > Porto Alegre - RS
>> > > 2010/1/25 Felipe Borges <felipeu...@gmail.com>
>> > > Assim como vc nao aceita o argumento que Webforms sao mais produtivos, >> > >> discordo completamente da sua posicao: "Dizer que MVC não é produtivo >> é >> > >> uma grande mentira! E se sua equipe só é produtiva com webforms, >> então há >> > >> algo errado."
>> > >> Trabalho há bastante tempo com webforms e estou comecando agora com >> MVC e >> > >> na minha opiniao até o momento Webforms é sim muito mais produtivo do >> que >> > >> MVC, pode ser que com o tempo me acostume com o MVC e consiga uma boa >> > >> produtividade, mas a curva de aprendizado existe, entao pode nao ser >> algo >> > >> errado com a equipe.
>> > >> Não digo que o MVC nao eh produtivo, mas ate o momento posso afirmar >> que >> > >> em produtividade ele perde para o Webforms, mas estou procurando >> estudar e >> > >> enteder cada vez mais o MVC para ter certeza das suas qualidades e >> tentar >> > >> atingir uma melhor produtividade, por isso estou utilizando em alguns >> > >> projetos.
>> > >>> Trabalho com webforms há uns 3 anos, é um pouco menos de tempo que >> tenho >> > >>> de desenvolvimento (yeah, I'm young).
>> > >>> Dizer que MVC não é produtivo é uma grande mentira! E se sua equipe >> só é >> > >>> produtiva com webforms, então há algo errado.
>> > >>> Trabalhei em projetos PHP(usando CodeIgniter como framework MVC) e >> Rails >> > >>> por exemplo, sem nenhum tipo de controle drag'n'drop, muito menos >> IDE, e os >> > >>> projetos foram feitos, entregues, dentro do prazo, com satisfação, >> etc.
>> > >>> Alguns dizem "No meu sistema não é preciso ter performance e nem >> validar >> > >>> no W3C, etc". Se você entrega um sistema lento, sem padrões, isso é >> um >> > >>> problema seu e do seu cliente, não chame isso de produtividade!
>> > >>> Eu não execro os webforms, mas não aceito o argumento de que são >> mais >> > >>> produtivos por que possuem suporte da IDE e controles drag'n'drop.
>> > >>> 2010/1/25 Juan Pedro A. Lopes <zerova...@gmail.com>
>> > >>> Eu também estou envolvido com programação há mais de 10 anos e, >> assim >> > >>>> como você, sempre preferi trabalhar com o back-end da aplicação, em >> vez de >> > >>>> ficar às voltas com UI. Entretanto, não tem como guiar equipes sem >> conhecer >> > >>>> as tecnologias nas quais elas trabalham a fundo. Trabalhei com >> WebForms >> > >>>> intensivamente por 6 meses. Foi o suficiente para odiá-lo do fundo >> do meu >> > >>>> coração. Posso estar sendo extremista, mas qualquer pessoa que se >> importe >> > >>>> com a elegância de um código se incomoda com o a desorganização que >> ficam as >> > >>>> páginas ASPX. Ainda mais vendo o HTML que elas geram.
>> > >>>> WebForms só é fácil se você confia 100% no Visual Studio. E mesmo >> assim >> > >>>> ele te amarra de uma forma inacreditável.
>> > >>>> O ASP.NET MVC ainda está meio verde, mas ele se propõe a se >> parecer com >> > >>>> o ActionPack do Rails. Se você não conhece, recomendo que estude >> sobre ele. >> > >>>> A idela é genial.
>> > >>>> Todo mundo aqui na empresa teve um momento de dizer o mesmo que >> você: >> > >>>> "por que eu vou abandonar tudo o que o WebForms me trouxe >> (controles, >> > >>>> patterns, etc.) para trabalhar com HTML?". Eu nunca consegui >> convencer >> > >>>> ninguém sem mostrar código. Por isso realizamos diversos Coding >> Dojos aqui >> > >>>> na empresa para mostrar como e porque o ASP.NET MVC came to kick >> > >>>> WebForms' ass out. É simplesmente fantástico.
>> > >>>> Entretanto, o único conselho que eu dou pra qualquer pessoa que >> entre no >> > >>>> ASP.NET MVC é o mesmo que dou para quem aprende Rails ou Karate: >> > >>>> entenda o porquê das coisas antes de
Sim, Edmilson, concordo com vc. Acho que este fórum é justamente o reflexo das maiores dúvidas de quem chegou a um certo estágio de programação, e as que vc citou abaixo com certeza passam por todos em algum momento da carreira.
Acho que estas perguntas ciclicas são interessantes para acompanharmos qual a evolução que acontece com cada campo destes, e com certeza eles evoluem muito rapidamente. Assim, não fico muito chateado com os mesmos temas indo e vindo, mas eu pelo menos tento só falar a mesma coisa quando vejo que alguem não viu a thread anterior! :-).
Acho que seria muito legal se alguem tivesse um tempo de colocar, na página do .dotnetarchitects, uma visão imparcial de cada um destes temas, com prós e contras já discutidos ad nauseum nesta lista... Isto no minimo pouparia tempo na thread, o que acham?
> sinto com se estivesse "loop" as discussões são basicamente as > mesmas: > Modelo Rico X Modelo Anemico; > Asp.Net WebForms X Asp.Net MVC; > Metodos Ageis x Não Ageis; > VB.Net X C#; > TDD x Não TDD; > Dot.Net x O resto das tecnologias de desenvolvimento de Software. E > por ai vai......
> As tecnologias/metodologias estão ai para "todos os gostos", todas > elas tem seus prós e contras. Cabe a nós, que somos profissionais da àrea, > conhece-las o suficiente para poder aplicar nos cenários onde aquela > tecnologia/metodologia melhor atender aos requisitos. Toda nova > tecnologia/metodologia lançada promete mil e uma vantagens sobre as > anteriores, que sempre terá alguma vantagem, eu não discordo. Porém, > analisando profundamente todas também tem suas desvantagens.
> As vezes parace que esquecemos que estamos fazendo software para outras > pessoas usarem. O que o usuario final do sistema quer é um sistema simples > de utilizar e que atenda plenamente as requisitos que foram solicitados. Se > o html esta "feio" o usuario final não vai nem saber, mas se ao inves de um > simples click num checkBox ele tiver que clicar em um monte de links e ficar > pulando de página em página para conseguir juntar a informação que ele > necessita, pode ter certeza que, neste momento, a mãe de quem fez o > software é lembrada e não de uma maneira boa.
> Tenho visto mutsas promessas de código facil de fazer, manter, e > extender. Promessas de sistemas bug-free, de sistemas que serão entregues > com sucesso total, de que se o sistema for muito complexo, será mais facil > de fazer, etc, etc.
> Eu tenho muita fé que todas estas promessas são verdadeiras, por isso > tenho estudado esta montanha de sopa de letras que temos a disposição, > ainda não estou convencido de que todas as promessas são verdadeiras, mas > TENHO FÉ!!
> -- > Você recebeu esta mensagem porque faz parte do grupo .Net Architects > hospedado no Google Groups. > Para postar envie uma mensagem para dotnetarchitects@googlegroups.com > Para sair do grupo envie uma mensagem para > dotnetarchitects+unsubscribe@googlegroups.com<dotnetarchitects%2Bunsubscrib e@googlegroups.com> > Para mais opções visite o grupo em > http://groups.google.com/group/dotnetarchitects?hl=pt-br
Concordo com o Alexandre e repito um parágrafo dele:
"Outro ponto que pra mim é fundamental é a capacidade de se "automatizar" determinadas operações, facilitando o uso de frameworks. Com MVC, isto é extremamente fácil de fazer (nós temos a nossa própria viewengine p.ex.)... No web.forms, nós tentamos fazer frameworks por 10 anos, sem sucesso. E isto sim, afeta produtividade (mas é um caso muito particular nosso)."
Quando podemos automatizar algo que costumeiramente fazemos, nos tornamos mais produtivos e se automatizamos nossa chance de ter erros é menor e a codificação tende a ficar melhor, sem falar que uma manutenção é mais simples !
Posso sitar um exemplo meu. Tinha problemas para listagem de dados ... não gostei dos plugins jquery que achei porque eles eram muito mais do que eu precisava . Sou um tanto chato com isso e se preciso de algo que pode ter 5 kb porque pegarei um plugin de 60 kb? No final resolvi fazer o seguinte: Todas minhas classes que possibilitavam listagens eram decoradas com atributos específicos para a listagem. Então aí criei um método (extension) que lia os atributos e montava o html usando um loop simples .... para completar peguei um plugin para ordenação e tudo ficou lindo maravilhoso !!!
Veja bem ... um método, alguns atributos e tive um grid como eu desejava podendo fazer uma chamada a "Html.Grid(dados, config)" tendo uma listagem pronta!!! A meu ver isso é produtividade com qualidade ... o que é MUITO importante !!
Não podemos pensar apenas na produtividade, a qualidade não deve ser deixada de lado !!
> Não são tão extremista como o Juan, mas compartilho a opinião dele de que > webforms are evil. Mas acho que não tem nada a ver com produtividade ou > elegancia, aliás, pra projetos pequenos é possível ser bem produtivo em > webforms.
> O que eu acho é que para telas complexas, o webforms gera um código que > tende a ser dificil de manter com o tempo. A interação entre os controles, o > ciclo de vida do webform, a complicação de viewstate etc., fazem com que as > telas fiquem um pesadelo. Eu falo por experiencia propria, nós temos > sistemas muito antigos, com páginas feitas em ASP.NET classico, que são > simplesmente inviáveis de manter.
> Outro ponto que pra mim é fundamental é a capacidade de se "automatizar" > determinadas operações, facilitando o uso de frameworks. Com MVC, isto é > extremamente fácil de fazer (nós temos a nossa própria viewengine p.ex.)... > No web.forms, nós tentamos fazer frameworks por 10 anos, sem sucesso. E isto > sim, afeta produtividade (mas é um caso muito particular nosso).
> Então, concordo com o que outros falaram. Para um projeto pequeno e que não > vá crescer (dificil garantir isto né?), tanto faz, talvez até o webforms > tenha um v0 menor. Agora pra projetos de maior porte e se for necessário > usar frameworks de interface, eu acho que o MVC é mais adequado. Hoje eu nem > concebo iniciar um projeto em webforms.
> 2010/1/25 Henrique Jacob <analista....@gmail.com>
> Vms lá pessoal!
>> Não precisamos brigar....
>> Concordo com o comentário que diz que podemos ter implementações >> limpas nas duas tecnologias, que isso depende de quem está usando...
>> Mas o que quero entender é o seguinte... PQ é melhor usar o .NET MVC >> e não o WebForms... é melhor pq tenho controle de tudo? pq posso usar >> e abusar de Jquery? é esse o motivo?
>> Se é pq temos o poder nas mãos, quero entender pq o rejeitamos no >> início da década?
>> Não quero causar polêmicas... Não quero saber quem cospe mais >> longe... Não tenho mais idade... Gostaria de uma análise como a feita >> por nosso amigo no blog http://sourcerule.wordpress.com/, pensar. Acho >> que é esse o termo. Desculpem até agora não vi nenhum comentário sobre >> o WF e o .NET MVC que não seja uma "copia" do que dizem.... >> Infelizmente, acho eu, que estamos rodeados de tanta informação que >> perdemos a aptidão de pensar de forma analítica e própria...
>> Quem conhece a música do Zé Ramalho Vida de GADO.... As vezes vejo >> isso.. Só mais do mesmo, tal qual os EMOS (nada contra) mas todos >> iguais... Cadê a identidade própria (me incluo no contexto)...
>> On 25 jan, 14:05, Ricardo Rocha <ricardorocha....@gmail.com> wrote: >> > Pode-se comparar produtividade quando se tem domínio nas tecnologias !!!
>> > Dizer que webforms é mais produtivo do que o Asp.Net MVC sem conhecer o >> mvc >> > bem, é um equívoco, e vice-versa !!
>> > Eu, pessoalmente, gosto muito do MVC. Tenho um controle muito bom sobre >> tudo >> > e tudo funciona bem para minhas necessidades. Nunca gostei do arrastar e >> > soltar .... o não saber o que será gerado ou o funcionamento sempre me >> > "assustou".
>> > Com o MVC tenho controle sobre tudo que está funcionando. Produtividade >> é >> > relativa, enquanto o webforms usa e abusa dos componentes que rodam no >> > server, o MVC abusa do jQuery (e eu fico com o jQuery ... hehehe). Há >> > plugins para jQuery em tudo que é canto de tudo que é tipo e para tudo >> que é >> > funcionalidade ... e é apenas um js (normalmente pequeno) que pode >> inclusive >> > ser aberto e retirado o que não será útil para ter melhor performance >> !!!
>> > Arrastar um TextBox e soltar na tela ou escrever um Html.TextBox não tem >> > muita diferença !! (apesar de podermos arrastar controles Html no MVC >> também >> > !!!)
>> > Analisar produtividade é para quem conhece realmente a fundo as duas >> > tecnologias !!! >> > Com certeza código limpo é possível obter com as duas tecnologias, porém >> > talvez não com a mesma facilidade. Enquanto uma é nativamente mais >> "suja", a >> > outra é nativamente mais "limpa" ... mas ambas podem ser "sujas" ou >> > "limpas", depende de quem usa !!
>> > []'s
>> > Ricardo José Alves da Rocha >> > Porto Alegre - RS
>> > > 2010/1/25 Felipe Borges <felipeu...@gmail.com>
>> > > Assim como vc nao aceita o argumento que Webforms sao mais produtivos, >> > >> discordo completamente da sua posicao: "Dizer que MVC não é produtivo >> é >> > >> uma grande mentira! E se sua equipe só é produtiva com webforms, >> então há >> > >> algo errado."
>> > >> Trabalho há bastante tempo com webforms e estou comecando agora com >> MVC e >> > >> na minha opiniao até o momento Webforms é sim muito mais produtivo do >> que >> > >> MVC, pode ser que com o tempo me acostume com o MVC e consiga uma boa >> > >> produtividade, mas a curva de aprendizado existe, entao pode nao ser >> algo >> > >> errado com a equipe.
>> > >> Não digo que o MVC nao eh produtivo, mas ate o momento posso afirmar >> que >> > >> em produtividade ele perde para o Webforms, mas estou procurando >> estudar e >> > >> enteder cada vez mais o MVC para ter certeza das suas qualidades e >> tentar >> > >> atingir uma melhor produtividade, por isso estou utilizando em alguns >> > >> projetos.
>> > >>> Trabalho com webforms há uns 3 anos, é um pouco menos de tempo que >> tenho >> > >>> de desenvolvimento (yeah, I'm young).
>> > >>> Dizer que MVC não é produtivo é uma grande mentira! E se sua equipe >> só é >> > >>> produtiva com webforms, então há algo errado.
>> > >>> Trabalhei em projetos PHP(usando CodeIgniter como framework MVC) e >> Rails >> > >>> por exemplo, sem nenhum tipo de controle drag'n'drop, muito menos >> IDE, e os >> > >>> projetos foram feitos, entregues, dentro do prazo, com satisfação, >> etc.
>> > >>> Alguns dizem "No meu sistema não é preciso ter performance e nem >> validar >> > >>> no W3C, etc". Se você entrega um sistema lento, sem padrões, isso é >> um >> > >>> problema seu e do seu cliente, não chame isso de produtividade!
>> > >>> Eu não execro os webforms, mas não aceito o argumento de que são >> mais >> > >>> produtivos por que possuem suporte da IDE e controles drag'n'drop.
>> > >>> 2010/1/25 Juan Pedro A. Lopes <zerova...@gmail.com>
>> > >>> Eu também estou envolvido com programação há mais de 10 anos e, >> assim >> > >>>> como você, sempre preferi trabalhar com o back-end da aplicação, em >> vez de >> > >>>> ficar às voltas com UI. Entretanto, não tem como guiar equipes sem >> conhecer >> > >>>> as tecnologias nas quais elas trabalham a fundo. Trabalhei com >> WebForms >> > >>>> intensivamente por 6 meses. Foi o suficiente para odiá-lo do fundo >> do meu >> > >>>> coração. Posso estar sendo extremista, mas qualquer pessoa que se >> importe >> > >>>> com a elegância de um código se incomoda com o a desorganização que >> ficam as >> > >>>> páginas ASPX. Ainda mais vendo o HTML que elas geram.
>> > >>>> WebForms só é fácil se você confia 100% no Visual Studio. E mesmo >> assim >> > >>>> ele te amarra de uma forma inacreditável.
>> > >>>> O ASP.NET MVC ainda está meio verde, mas ele se propõe a se >> parecer com >> > >>>> o
Para quem achou meu comentário ofensivo, não foi minha intenção.
Não acho o MVC a bala que matou Kennedy. Acho WebForm velho e pode ser melhor.
Se for comparar tecnologia olhe antes qual é o futuro e o futuro não é MVC. O futuro é separação de camadas é, mas não é só o MVC que faz isso.
Quer usar o MVC OK, mas saiba que apenas é uma forma diferente de resolver os mesmos problemas.
Querem saber qual eu acho o melhor modelo de UI? HTML + Serviços! GMail é assim, Hotmail é assim, HealthVault é assim, todos os softwares desenvolvidos pelos grandes estão sendo assim, não que isso seja o melhor, apenas um demonstrativo do que elas mesmas pensam sobre a tecnologia que elas usam.
Quer fazer um software Web, olhe o como a Microsoft fez os delas ué. Hotmail, MSN, Bing, OfficeWeb, será que é tudo MVC?
Pessoal, não sou xiita, mas se a Microsoft faz algo que não usa, é porque ela tem bons motivos para adotar uma outra solução.
Quem fala isso não sou eu. Mas Yahoo, Google, Oracle, todas as big software houses, estão construindo seus softwares com base em HTML + Services, não importa se é Java, Ruby, etc. Quer usar jQuery ótimo, eu uso e realmente é muito bom, todos os grandes tbm usam e vão direcionar seus desenvolvimentos nessa base.
Testabilidade? WebServices, tá bom para você? Para quê ModelBinders se eu posso serializar e deserializar objetos em javascript e usá-los como DTO? Anemico? talvez.
Minha opinião é, está no WebForm e sair então vá logo para quem será o futuro, HTML+Services/Silverlight/Flash+Flex. Sair do MVP para o MVC acho idiotice.
Se você vai começar agora então comece logo pelo MVC, afinal tem caracteristicas interessantes nele que você não tem no MVP.
Não sou contra o MVC só não acho ele tão lindão assim. Pois tudo que ele faz dá para fazer de outra forma até mesmo no MVP.
Eu desenvolvo no MVP sem me orientar a eventos e comportamentos, logo ele para mim é extremamente testável. Não uso Viewstate para nada, sou completamente Restiful com o ASP.NET.
Com um click sou capaz de te dar uma biblioteca MVC para ASP 2.0 se quiser, que faz a mesma coisa que o MVC do .NET. E outra dá para testar o ASP antigo com unit test tbm tão simples como.
Enfim, não quero levantar poeira, não quero ofender, mas falar que o MVC é lindão. Depende do gosto sexual de cada um hehehehehehe.
> Não são tão extremista como o Juan, mas compartilho a opinião dele de que > webforms are evil. Mas acho que não tem nada a ver com produtividade ou > elegancia, aliás, pra projetos pequenos é possível ser bem produtivo em > webforms.
> O que eu acho é que para telas complexas, o webforms gera um código que > tende a ser dificil de manter com o tempo. A interação entre os controles, o > ciclo de vida do webform, a complicação de viewstate etc., fazem com que as > telas fiquem um pesadelo. Eu falo por experiencia propria, nós temos > sistemas muito antigos, com páginas feitas em ASP.NET classico, que são > simplesmente inviáveis de manter.
> Outro ponto que pra mim é fundamental é a capacidade de se "automatizar" > determinadas operações, facilitando o uso de frameworks. Com MVC, isto é > extremamente fácil de fazer (nós temos a nossa própria viewengine p.ex.)... > No web.forms, nós tentamos fazer frameworks por 10 anos, sem sucesso. E isto > sim, afeta produtividade (mas é um caso muito particular nosso).
> Então, concordo com o que outros falaram. Para um projeto pequeno e que não > vá crescer (dificil garantir isto né?), tanto faz, talvez até o webforms > tenha um v0 menor. Agora pra projetos de maior porte e se for necessário > usar frameworks de interface, eu acho que o MVC é mais adequado. Hoje eu nem > concebo iniciar um projeto em webforms.
> 2010/1/25 Henrique Jacob <analista....@gmail.com>
> Vms lá pessoal!
>> Não precisamos brigar....
>> Concordo com o comentário que diz que podemos ter implementações >> limpas nas duas tecnologias, que isso depende de quem está usando...
>> Mas o que quero entender é o seguinte... PQ é melhor usar o .NET MVC >> e não o WebForms... é melhor pq tenho controle de tudo? pq posso usar >> e abusar de Jquery? é esse o motivo?
>> Se é pq temos o poder nas mãos, quero entender pq o rejeitamos no >> início da década?
>> Não quero causar polêmicas... Não quero saber quem cospe mais >> longe... Não tenho mais idade... Gostaria de uma análise como a feita >> por nosso amigo no blog http://sourcerule.wordpress.com/, pensar. Acho >> que é esse o termo. Desculpem até agora não vi nenhum comentário sobre >> o WF e o .NET MVC que não seja uma "copia" do que dizem.... >> Infelizmente, acho eu, que estamos rodeados de tanta informação que >> perdemos a aptidão de pensar de forma analítica e própria...
>> Quem conhece a música do Zé Ramalho Vida de GADO.... As vezes vejo >> isso.. Só mais do mesmo, tal qual os EMOS (nada contra) mas todos >> iguais... Cadê a identidade própria (me incluo no contexto)...
>> On 25 jan, 14:05, Ricardo Rocha <ricardorocha....@gmail.com> wrote: >> > Pode-se comparar produtividade quando se tem domínio nas tecnologias !!!
>> > Dizer que webforms é mais produtivo do que o Asp.Net MVC sem conhecer o >> mvc >> > bem, é um equívoco, e vice-versa !!
>> > Eu, pessoalmente, gosto muito do MVC. Tenho um controle muito bom sobre >> tudo >> > e tudo funciona bem para minhas necessidades. Nunca gostei do arrastar e >> > soltar .... o não saber o que será gerado ou o funcionamento sempre me >> > "assustou".
>> > Com o MVC tenho controle sobre tudo que está funcionando. Produtividade >> é >> > relativa, enquanto o webforms usa e abusa dos componentes que rodam no >> > server, o MVC abusa do jQuery (e eu fico com o jQuery ... hehehe). Há >> > plugins para jQuery em tudo que é canto de tudo que é tipo e para tudo >> que é >> > funcionalidade ... e é apenas um js (normalmente pequeno) que pode >> inclusive >> > ser aberto e retirado o que não será útil para ter melhor performance >> !!!
>> > Arrastar um TextBox e soltar na tela ou escrever um Html.TextBox não tem >> > muita diferença !! (apesar de podermos arrastar controles Html no MVC >> também >> > !!!)
>> > Analisar produtividade é para quem conhece realmente a fundo as duas >> > tecnologias !!! >> > Com certeza código limpo é possível obter com as duas tecnologias, porém >> > talvez não com a mesma facilidade. Enquanto uma é nativamente mais >> "suja", a >> > outra é nativamente mais "limpa" ... mas ambas podem ser "sujas" ou >> > "limpas", depende de quem usa !!
>> > []'s
>> > Ricardo José Alves da Rocha >> > Porto Alegre - RS
>> > > 2010/1/25 Felipe Borges <felipeu...@gmail.com>
>> > > Assim como vc nao aceita o argumento que Webforms sao mais produtivos, >> > >> discordo completamente da sua posicao: "Dizer que MVC não é produtivo >> é >> > >> uma grande mentira! E se sua equipe só é produtiva com webforms, >> então há >> > >> algo errado."
>> > >> Trabalho há bastante tempo com webforms e estou comecando agora com >> MVC e >> > >> na minha opiniao até o momento Webforms é sim muito mais produtivo do >> que >> > >> MVC, pode ser que com o tempo me acostume com o MVC e consiga uma boa >> > >> produtividade, mas a curva de aprendizado existe, entao pode nao ser >> algo >> > >> errado com a equipe.
>> > >> Não digo que o MVC nao eh produtivo, mas ate o momento posso afirmar >> que >> > >> em produtividade ele perde para o Webforms, mas estou procurando >> estudar e >> > >> enteder cada vez mais o MVC para ter certeza das suas qualidades e >> tentar >> > >> atingir uma melhor produtividade, por isso estou utilizando em alguns >> > >> projetos.
>> > >>> Trabalho com webforms há uns 3 anos, é um pouco menos de tempo que >> tenho >> > >>> de desenvolvimento (yeah, I'm young).
>> > >>> Dizer que MVC não é produtivo é uma grande mentira! E se sua equipe >> só é >> > >>> produtiva com webforms, então há algo errado.
>> > >>> Trabalhei em projetos PHP(usando CodeIgniter como framework MVC) e >> Rails >> > >>> por exemplo, sem nenhum tipo de controle drag'n'drop, muito menos >> IDE, e os >> > >>> projetos foram feitos, entregues, dentro do prazo, com satisfação, >> etc.
>> > >>> Alguns dizem "No meu sistema não é preciso ter performance e nem >> validar >> > >>> no W3C, etc". Se você entrega um sistema lento, sem padrões, isso é >> um >> > >>> problema seu e do seu cliente, não chame isso de produtividade!
>> > >>> Eu não execro os webforms, mas não aceito o argumento de que são >> mais >> > >>> produtivos por que possuem suporte da IDE e controles drag'n'drop.
> Sim, Edmilson, concordo com vc. Acho que este fórum é justamente o reflexo > das maiores dúvidas de quem chegou a um certo estágio de programação, e as > que vc citou abaixo com certeza passam por todos em algum momento da > carreira.
> Acho que estas perguntas ciclicas são interessantes para acompanharmos qual > a evolução que acontece com cada campo destes, e com certeza eles evoluem > muito rapidamente. Assim, não fico muito chateado com os mesmos temas indo e > vindo, mas eu pelo menos tento só falar a mesma coisa quando vejo que alguem > não viu a thread anterior! :-).
> Acho que seria muito legal se alguem tivesse um tempo de colocar, na página > do .dotnetarchitects, uma visão imparcial de cada um destes temas, com prós > e contras já discutidos ad nauseum nesta lista... Isto no minimo pouparia > tempo na thread, o que acham?
> 2010/1/25 edmilson hora <edmilson_h...@yahoo.com.br>
> Pessoal,
>> sinto com se estivesse "loop" as discussões são basicamente as >> mesmas: >> Modelo Rico X Modelo Anemico; >> Asp.Net WebForms X Asp.Net MVC; >> Metodos Ageis x Não Ageis; >> VB.Net X C#; >> TDD x Não TDD; >> Dot.Net x O resto das tecnologias de desenvolvimento de >> Software. E por ai vai......
>> As tecnologias/metodologias estão ai para "todos os gostos", todas >> elas tem seus prós e contras. Cabe a nós, que somos profissionais da àrea, >> conhece-las o suficiente para poder aplicar nos cenários onde aquela >> tecnologia/metodologia melhor atender aos requisitos. Toda nova >> tecnologia/metodologia lançada promete mil e uma vantagens sobre as >> anteriores, que sempre terá alguma vantagem, eu não discordo. Porém, >> analisando profundamente todas também tem suas desvantagens.
>> As vezes parace que esquecemos que estamos fazendo software para >> outras pessoas usarem. O que o usuario final do sistema quer é um sistema >> simples de utilizar e que atenda plenamente as requisitos que foram >> solicitados. Se o html esta "feio" o usuario final não vai nem saber, mas >> se ao inves de um simples click num checkBox ele tiver que clicar em um >> monte de links e ficar pulando de página em página para conseguir juntar a >> informação que ele necessita, pode ter certeza que, neste momento, a mãe de >> quem fez o software é lembrada e não de uma maneira boa.
>> Tenho visto mutsas promessas de código facil de fazer, manter, e >> extender. Promessas de sistemas bug-free, de sistemas que serão entregues >> com sucesso total, de que se o sistema for muito complexo, será mais facil >> de fazer, etc, etc.
>> Eu tenho muita fé que todas estas promessas são verdadeiras, por isso >> tenho estudado esta montanha de sopa de letras que temos a disposição, >> ainda não estou convencido de que todas as promessas são verdadeiras, mas >> TENHO FÉ!!
>> -- >> Você recebeu esta mensagem porque faz parte do grupo .Net Architects >> hospedado no Google Groups. >> Para postar envie uma mensagem para dotnetarchitects@googlegroups.com >> Para sair do grupo envie uma mensagem para >> dotnetarchitects+unsubscribe@googlegroups.com<dotnetarchitects%2Bunsubscrib e@googlegroups.com> >> Para mais opções visite o grupo em >> http://groups.google.com/group/dotnetarchitects?hl=pt-br
> -- > Você recebeu esta mensagem porque faz parte do grupo .Net Architects > hospedado no Google Groups. > Para postar envie uma mensagem para dotnetarchitects@googlegroups.com > Para sair do grupo envie uma mensagem para > dotnetarchitects+unsubscribe@googlegroups.com<dotnetarchitects%2Bunsubscrib e@googlegroups.com> > Para mais opções visite o grupo em > http://groups.google.com/group/dotnetarchitects?hl=pt-br
Alguém que não se preocupa com o lixo gerado pelos wizards do VS não vai se preocupar com o que tem nos plugins !!!
É uma questão de perfil de cada pessoa !!!
Como já foi repetidamente falado, dá para fazer muita porcaria usando o MVC ou qualquer tecnologia, padrão ou metodologia !!! Quam faz isso são as pessoas e nao o que elas usam em si!!!
> Só uma pequena observacao, sobre essa colocação do Ricardo Rocha: > "MVC abusa do jQuery (e eu fico com o jQuery ... hehehe). Há plugins para > jQuery em tudo que é canto de tudo que é tipo e para tudo que é > funcionalidade ... e é apenas um js (normalmente pequeno) que pode inclusive > ser aberto e retirado o que não será útil para ter melhor performance !!!"
> Sera que os desenvolvedores que usam MVC procuram entender estes JS/!?!?? > Duvido que mtos deles param pra analisar o q esta dentro destes plugins... > simplesmente pegam um tutorial de como inseri-los na pagina e seguem > usando... ou seja, nao seria similar ao arrastar e soltar do webforms?!? > Poluir a tela com javascript dos controles que acessam o server seria pior > do que os javascripts do Jquery?!? Nao quero polemizar, como disse estou > comecando com MVC, soh estou interessado em saber das diferencas...
>> Não são tão extremista como o Juan, mas compartilho a opinião dele de que >> webforms are evil. Mas acho que não tem nada a ver com produtividade ou >> elegancia, aliás, pra projetos pequenos é possível ser bem produtivo em >> webforms.
>> O que eu acho é que para telas complexas, o webforms gera um código que >> tende a ser dificil de manter com o tempo. A interação entre os controles, o >> ciclo de vida do webform, a complicação de viewstate etc., fazem com que as >> telas fiquem um pesadelo. Eu falo por experiencia propria, nós temos >> sistemas muito antigos, com páginas feitas em ASP.NET classico, que são >> simplesmente inviáveis de manter.
>> Outro ponto que pra mim é fundamental é a capacidade de se "automatizar" >> determinadas operações, facilitando o uso de frameworks. Com MVC, isto é >> extremamente fácil de fazer (nós temos a nossa própria viewengine p.ex.)... >> No web.forms, nós tentamos fazer frameworks por 10 anos, sem sucesso. E isto >> sim, afeta produtividade (mas é um caso muito particular nosso).
>> Então, concordo com o que outros falaram. Para um projeto pequeno e que >> não vá crescer (dificil garantir isto né?), tanto faz, talvez até o webforms >> tenha um v0 menor. Agora pra projetos de maior porte e se for necessário >> usar frameworks de interface, eu acho que o MVC é mais adequado. Hoje eu nem >> concebo iniciar um projeto em webforms.
>> 2010/1/25 Henrique Jacob <analista....@gmail.com>
>> Vms lá pessoal!
>>> Não precisamos brigar....
>>> Concordo com o comentário que diz que podemos ter implementações >>> limpas nas duas tecnologias, que isso depende de quem está usando...
>>> Mas o que quero entender é o seguinte... PQ é melhor usar o .NET MVC >>> e não o WebForms... é melhor pq tenho controle de tudo? pq posso usar >>> e abusar de Jquery? é esse o motivo?
>>> Se é pq temos o poder nas mãos, quero entender pq o rejeitamos no >>> início da década?
>>> Não quero causar polêmicas... Não quero saber quem cospe mais >>> longe... Não tenho mais idade... Gostaria de uma análise como a feita >>> por nosso amigo no blog http://sourcerule.wordpress.com/, pensar. Acho >>> que é esse o termo. Desculpem até agora não vi nenhum comentário sobre >>> o WF e o .NET MVC que não seja uma "copia" do que dizem.... >>> Infelizmente, acho eu, que estamos rodeados de tanta informação que >>> perdemos a aptidão de pensar de forma analítica e própria...
>>> Quem conhece a música do Zé Ramalho Vida de GADO.... As vezes vejo >>> isso.. Só mais do mesmo, tal qual os EMOS (nada contra) mas todos >>> iguais... Cadê a identidade própria (me incluo no contexto)...
>>> On 25 jan, 14:05, Ricardo Rocha <ricardorocha....@gmail.com> wrote: >>> > Pode-se comparar produtividade quando se tem domínio nas tecnologias >>> !!!
>>> > Dizer que webforms é mais produtivo do que o Asp.Net MVC sem conhecer o >>> mvc >>> > bem, é um equívoco, e vice-versa !!
>>> > Eu, pessoalmente, gosto muito do MVC. Tenho um controle muito bom sobre >>> tudo >>> > e tudo funciona bem para minhas necessidades. Nunca gostei do arrastar >>> e >>> > soltar .... o não saber o que será gerado ou o funcionamento sempre me >>> > "assustou".
>>> > Com o MVC tenho controle sobre tudo que está funcionando. Produtividade >>> é >>> > relativa, enquanto o webforms usa e abusa dos componentes que rodam no >>> > server, o MVC abusa do jQuery (e eu fico com o jQuery ... hehehe). Há >>> > plugins para jQuery em tudo que é canto de tudo que é tipo e para tudo >>> que é >>> > funcionalidade ... e é apenas um js (normalmente pequeno) que pode >>> inclusive >>> > ser aberto e retirado o que não será útil para ter melhor performance >>> !!!
>>> > Arrastar um TextBox e soltar na tela ou escrever um Html.TextBox não >>> tem >>> > muita diferença !! (apesar de podermos arrastar controles Html no MVC >>> também >>> > !!!)
>>> > Analisar produtividade é para quem conhece realmente a fundo as duas >>> > tecnologias !!! >>> > Com certeza código limpo é possível obter com as duas tecnologias, >>> porém >>> > talvez não com a mesma facilidade. Enquanto uma é nativamente mais >>> "suja", a >>> > outra é nativamente mais "limpa" ... mas ambas podem ser "sujas" ou >>> > "limpas", depende de quem usa !!
>>> > []'s
>>> > Ricardo José Alves da Rocha >>> > Porto Alegre - RS
>>> > > 2010/1/25 Felipe Borges <felipeu...@gmail.com>
>>> > > Assim como vc nao aceita o argumento que Webforms sao mais >>> produtivos, >>> > >> discordo completamente da sua posicao: "Dizer que MVC não é >>> produtivo é >>> > >> uma grande mentira! E se sua equipe só é produtiva com webforms, >>> então há >>> > >> algo errado."
>>> > >> Trabalho há bastante tempo com webforms e estou comecando agora com >>> MVC e >>> > >> na minha opiniao até o momento Webforms é sim muito mais produtivo >>> do que >>> > >> MVC, pode ser que com o tempo me acostume com o MVC e consiga uma >>> boa >>> > >> produtividade, mas a curva de aprendizado existe, entao pode nao ser >>> algo >>> > >> errado com a equipe.
>>> > >> Não digo que o MVC nao eh produtivo, mas ate o momento posso afirmar >>> que >>> > >> em produtividade ele perde para o Webforms, mas estou procurando >>> estudar e >>> > >> enteder cada vez mais o MVC para ter certeza das suas qualidades e >>> tentar >>> > >> atingir uma melhor produtividade, por isso estou utilizando em >>> alguns >>> > >> projetos.
>>> > >>> Trabalho com webforms há uns 3 anos, é um pouco menos de tempo que >>> tenho >>> > >>> de desenvolvimento (yeah, I'm young).
>>> > >>> Dizer que MVC não é produtivo é uma grande mentira! E se sua equipe >>> só é >>> > >>> produtiva com webforms, então há algo errado.
>>> > >>> Trabalhei em projetos PHP(usando CodeIgniter como framework MVC) e >>> Rails >>> > >>> por exemplo, sem nenhum tipo de controle drag'n'drop, muito menos >>> IDE, e os >>> > >>> projetos foram feitos, entregues, dentro do prazo, com satisfação, >>> etc.
>>> > >>> Alguns dizem "No meu sistema não é preciso ter performance e nem >>> validar >>> > >>> no W3C, etc". Se você entrega um sistema lento, sem padrões, isso é >>> um >>> > >>> problema seu e do seu cliente, não chame isso de produtividade!
>>> > >>> Eu não execro os webforms, mas não aceito o argumento de que são >>> mais >>> > >>> produtivos por que possuem suporte da IDE e controles drag'n'drop.
>>> > >>> 2010/1/25 Juan Pedro A. Lopes <zerova...@gmail.com>
>>> > >>> Eu também estou envolvido com programação há mais de 10 anos e, >>> assim >>> > >>>> como você, sempre preferi trabalhar com o back-end da aplicação, >>> em vez de >>> > >>>> ficar às voltas com UI. Entretanto, não tem como guiar equipes sem >>> conhecer >>> > >>>> as tecnologias nas quais elas trabalham a fundo. Trabalhei com >>> WebForms >>> > >>>> intensivamente por 6 meses. Foi o suficiente para odiá-lo do fundo >>> do meu >>> > >>>> coração. Posso estar sendo extremista, mas qualquer pessoa que se >>> importe >>> > >>>> com a elegância de um código se incomoda com o a desorganização >>> que ficam as >>> > >>>> páginas ASPX. Ainda mais vendo o HTML que elas geram.
>>> > >>>> WebForms só é fácil se você confia 100% no Visual Studio. E mesmo >>> assim >>> > >>>> ele te amarra de uma forma inacreditável.
>>> > >>>> O ASP.NET MVC ainda está meio verde, mas ele se propõe a se >>> parecer com >>> > >>>> o ActionPack do Rails. Se você não conhece,
Entao, esse tb eh meu pensamento, da mesma forma que da pra fazer porcaria com o MVC dá pra fazer coisas boas com o webforms.... isso na minha opiniao... Mas enfim, estou desenvolvendo o MVC atualmente mas ainda estou apanhando um pouco, mas logo terei mais argumentos para discutir aki!
> Alguém que não se preocupa com o lixo gerado pelos wizards do VS não vai se > preocupar com o que tem nos plugins !!!
> É uma questão de perfil de cada pessoa !!!
> Como já foi repetidamente falado, dá para fazer muita porcaria usando o MVC > ou qualquer tecnologia, padrão ou metodologia !!! Quam faz isso são as > pessoas e nao o que elas usam em si!!!
>> Só uma pequena observacao, sobre essa colocação do Ricardo Rocha: >> "MVC abusa do jQuery (e eu fico com o jQuery ... hehehe). Há plugins para >> jQuery em tudo que é canto de tudo que é tipo e para tudo que é >> funcionalidade ... e é apenas um js (normalmente pequeno) que pode inclusive >> ser aberto e retirado o que não será útil para ter melhor performance !!!"
>> Sera que os desenvolvedores que usam MVC procuram entender estes JS/!?!?? >> Duvido que mtos deles param pra analisar o q esta dentro destes plugins... >> simplesmente pegam um tutorial de como inseri-los na pagina e seguem >> usando... ou seja, nao seria similar ao arrastar e soltar do webforms?!? >> Poluir a tela com javascript dos controles que acessam o server seria pior >> do que os javascripts do Jquery?!? Nao quero polemizar, como disse estou >> comecando com MVC, soh estou interessado em saber das diferencas...
>>> Não são tão extremista como o Juan, mas compartilho a opinião dele de que >>> webforms are evil. Mas acho que não tem nada a ver com produtividade ou >>> elegancia, aliás, pra projetos pequenos é possível ser bem produtivo em >>> webforms.
>>> O que eu acho é que para telas complexas, o webforms gera um código que >>> tende a ser dificil de manter com o tempo. A interação entre os controles, o >>> ciclo de vida do webform, a complicação de viewstate etc., fazem com que as >>> telas fiquem um pesadelo. Eu falo por experiencia propria, nós temos >>> sistemas muito antigos, com páginas feitas em ASP.NET classico, que são >>> simplesmente inviáveis de manter.
>>> Outro ponto que pra mim é fundamental é a capacidade de se "automatizar" >>> determinadas operações, facilitando o uso de frameworks. Com MVC, isto é >>> extremamente fácil de fazer (nós temos a nossa própria viewengine p.ex.)... >>> No web.forms, nós tentamos fazer frameworks por 10 anos, sem sucesso. E isto >>> sim, afeta produtividade (mas é um caso muito particular nosso).
>>> Então, concordo com o que outros falaram. Para um projeto pequeno e que >>> não vá crescer (dificil garantir isto né?), tanto faz, talvez até o webforms >>> tenha um v0 menor. Agora pra projetos de maior porte e se for necessário >>> usar frameworks de interface, eu acho que o MVC é mais adequado. Hoje eu nem >>> concebo iniciar um projeto em webforms.
>>> 2010/1/25 Henrique Jacob <analista....@gmail.com>
>>> Vms lá pessoal!
>>>> Não precisamos brigar....
>>>> Concordo com o comentário que diz que podemos ter implementações >>>> limpas nas duas tecnologias, que isso depende de quem está usando...
>>>> Mas o que quero entender é o seguinte... PQ é melhor usar o .NET MVC >>>> e não o WebForms... é melhor pq tenho controle de tudo? pq posso usar >>>> e abusar de Jquery? é esse o motivo?
>>>> Se é pq temos o poder nas mãos, quero entender pq o rejeitamos no >>>> início da década?
>>>> Não quero causar polêmicas... Não quero saber quem cospe mais >>>> longe... Não tenho mais idade... Gostaria de uma análise como a feita >>>> por nosso amigo no blog http://sourcerule.wordpress.com/, pensar. Acho >>>> que é esse o termo. Desculpem até agora não vi nenhum comentário sobre >>>> o WF e o .NET MVC que não seja uma "copia" do que dizem.... >>>> Infelizmente, acho eu, que estamos rodeados de tanta informação que >>>> perdemos a aptidão de pensar de forma analítica e própria...
>>>> Quem conhece a música do Zé Ramalho Vida de GADO.... As vezes vejo >>>> isso.. Só mais do mesmo, tal qual os EMOS (nada contra) mas todos >>>> iguais... Cadê a identidade própria (me incluo no contexto)...
>>>> On 25 jan, 14:05, Ricardo Rocha <ricardorocha....@gmail.com> wrote: >>>> > Pode-se comparar produtividade quando se tem domínio nas tecnologias >>>> !!!
>>>> > Dizer que webforms é mais produtivo do que o Asp.Net MVC sem conhecer >>>> o mvc >>>> > bem, é um equívoco, e vice-versa !!
>>>> > Eu, pessoalmente, gosto muito do MVC. Tenho um controle muito bom >>>> sobre tudo >>>> > e tudo funciona bem para minhas necessidades. Nunca gostei do arrastar >>>> e >>>> > soltar .... o não saber o que será gerado ou o funcionamento sempre me >>>> > "assustou".
>>>> > Com o MVC tenho controle sobre tudo que está funcionando. >>>> Produtividade é >>>> > relativa, enquanto o webforms usa e abusa dos componentes que rodam no >>>> > server, o MVC abusa do jQuery (e eu fico com o jQuery ... hehehe). Há >>>> > plugins para jQuery em tudo que é canto de tudo que é tipo e para tudo >>>> que é >>>> > funcionalidade ... e é apenas um js (normalmente pequeno) que pode >>>> inclusive >>>> > ser aberto e retirado o que não será útil para ter melhor performance >>>> !!!
>>>> > Arrastar um TextBox e soltar na tela ou escrever um Html.TextBox não >>>> tem >>>> > muita diferença !! (apesar de podermos arrastar controles Html no MVC >>>> também >>>> > !!!)
>>>> > Analisar produtividade é para quem conhece realmente a fundo as duas >>>> > tecnologias !!! >>>> > Com certeza código limpo é possível obter com as duas tecnologias, >>>> porém >>>> > talvez não com a mesma facilidade. Enquanto uma é nativamente mais >>>> "suja", a >>>> > outra é nativamente mais "limpa" ... mas ambas podem ser "sujas" ou >>>> > "limpas", depende de quem usa !!
>>>> > []'s
>>>> > Ricardo José Alves da Rocha >>>> > Porto Alegre - RS
>>>> > > 2010/1/25 Felipe Borges <felipeu...@gmail.com>
>>>> > > Assim como vc nao aceita o argumento que Webforms sao mais >>>> produtivos, >>>> > >> discordo completamente da sua posicao: "Dizer que MVC não é >>>> produtivo é >>>> > >> uma grande mentira! E se sua equipe só é produtiva com webforms, >>>> então há >>>> > >> algo errado."
>>>> > >> Trabalho há bastante tempo com webforms e estou comecando agora com >>>> MVC e >>>> > >> na minha opiniao até o momento Webforms é sim muito mais produtivo >>>> do que >>>> > >> MVC, pode ser que com o tempo me acostume com o MVC e consiga uma >>>> boa >>>> > >> produtividade, mas a curva de aprendizado existe, entao pode nao >>>> ser algo >>>> > >> errado com a equipe.
>>>> > >> Não digo que o MVC nao eh produtivo, mas ate o momento posso >>>> afirmar que >>>> > >> em produtividade ele perde para o Webforms, mas estou procurando >>>> estudar e >>>> > >> enteder cada vez mais o MVC para ter certeza das suas qualidades e >>>> tentar >>>> > >> atingir uma melhor produtividade, por isso estou utilizando em >>>> alguns >>>> > >> projetos.
>>>> > >>> Trabalho com webforms há uns 3 anos, é um pouco menos de tempo que >>>> tenho >>>> > >>> de desenvolvimento (yeah, I'm young).
>>>> > >>> Dizer que MVC não é produtivo é uma grande mentira! E se sua >>>> equipe só é >>>> > >>> produtiva com webforms, então há algo errado.
>>>> > >>> Trabalhei em projetos PHP(usando CodeIgniter como framework MVC) e >>>> Rails >>>> > >>> por exemplo, sem nenhum tipo de controle drag'n'drop, muito menos >>>> IDE, e os >>>> > >>> projetos foram feitos, entregues, dentro do prazo, com satisfação, >>>> etc.
>>>> > >>> Alguns dizem "No meu sistema não é preciso ter performance e nem >>>> validar >>>> > >>> no W3C, etc". Se você entrega um sistema lento, sem padrões, isso >>>> é um >>>> > >>> problema seu e do seu cliente, não chame isso de produtividade!
>>>> > >>> Eu não execro os webforms, mas não aceito o argumento de que são >>>> mais >>>> > >>> produtivos por que possuem suporte da IDE e controles drag'n'drop.
>>>> > >>> 2010/1/25 Juan Pedro A. Lopes <zerova...@gmail.com>
>>>> > >>> Eu também estou envolvido com programação há mais de 10 anos e, >>>> assim >>>> > >>>> como você, sempre preferi trabalhar com o back-end da aplicação, >>>> em vez de >>>> > >>>> ficar às voltas com UI. Entretanto, não tem como guiar equipes >>>> sem conhecer >>>> > >>>> as tecnologias nas quais elas trabalham a fundo. Trabalhei com >>>> WebForms >>>> > >>>> intensivamente por 6 meses. Foi o
