Alguém ao meu lado simplesmente NÃO obtém o ASP.NET MVC? [fechadas]

Venho brincando com o ASP.NET MVC desde o CTP, e gosto de muitas coisas que eles fizeram, mas há coisas que simplesmente não entendo.

Por exemplo, baixei o beta1 e estou montando um pequeno site / currículo / blog pessoal. Aqui está um trecho da visualização ViewSinglePost:

 <%
        // Display the "Next and Previous" links
        if (ViewData.Model.PreviousPost != null || ViewData.Model.NextPost != null)
        {
            %> <div> <%

            if (ViewData.Model.PreviousPost != null)
            {
                %> <span style="float: left;"> <%
                    Response.Write(Html.ActionLink("<< " + ViewData.Model.PreviousPost.Subject, "view", new { id = ViewData.Model.PreviousPost.Id }));
                %> </span> <%
            }

            if (ViewData.Model.NextPost != null)
            {
                %> <span style="float: right;"> <%
                    Response.Write(Html.ActionLink(ViewData.Model.NextPost.Subject + " >>", "view", new { id = ViewData.Model.NextPost.Id }));
                %> </span> <%
            }
            %>
                   <div style="clear: both;" />
               </div> <%
        }
    %>

Repugnante! (Observe também que, como o HTML existe em HTML temporário, eu criarei um design real quando a funcionalidade estiver funcionando) .

Estou fazendo algo errado? Porque passei muitos dias sombrios no ASP clássico, e essa sopa de tags me lembra fortemente disso.

Todo mundo prega como você pode criar um HTML mais limpo. Adivinha? 1% de todas as pessoas analisam o HTML gerado. Para mim, eu não me importo se os Webforms atrapalharem meu recuo no HTML renderizado, desde que eu tenha um código fácil de manter ... Isso não é!

Então, converta-me, um cara duro de webforms, por que eu deveria desistir de minhas páginas ASPX bem formadas para isso?

Edit: Negrito a linha "temp Html / css" para que as pessoas fiquem furiosas com isso.

Comparado aos Web Forms, o MVC é simultaneamente uma abordagem de nível inferior à geração de HTML, com maior controle sobre a saída da página e uma abordagem de nível superior e mais orientada pela arquitetura. Deixe-me capturar Web Forms e MVC e mostrar por que acho que a comparação favorece Web Forms em muitas situações - desde que você não caia em algumas armadilhas clássicas de Web Forms.

Formulários da Web

No modelo de formulários da Web, suas páginas correspondem diretamente à solicitação de página do navegador. Portanto, se você estiver direcionando um usuário para uma lista de livros, provavelmente terá uma página em algum lugar chamada "Booklist.aspx" para a qual o direcionará. Nessa página, você precisará fornecer tudo o que é necessário para mostrar essa lista. Isso inclui código para extrair dados, aplicar qualquer lógica comercial e exibir os resultados. Se houver alguma lógica de arquitetura ou de roteamento afetando a página, você também precisará codificar a lógica de arquitetura na página. O bom desenvolvimento de formulários da Web geralmente envolve o desenvolvimento de um conjunto de classes de suporte em uma DLL separada (testável por unidade). Essas classes lidarão com lógica de negócios, acesso a dados e decisões de arquitetura / roteamento.

MVC

O MVC adota uma visão mais "arquitetônica" do desenvolvimento de aplicativos da Web: oferecendo um andaime padronizado sobre o qual construir. Ele também fornece ferramentas para gerar automaticamente classes de modelo, exibição e controlador dentro da arquitetura estabelecida. Por exemplo, no Ruby on Rails (apenas "Rails" daqui em diante) e no ASP.NET MVC, você sempre começará com uma estrutura de diretórios que reflete seu modelo geral de arquitetura de aplicativos da web. Para adicionar uma visualização, modelo e controlador, você usará um comando como o "Rails script / generate scaffold {modelname}" (o ASP.NET MVC oferece comandos semelhantes no IDE). Na classe de controlador resultante, haverá métodos ("Actions") para Index (show list), Show, New e Edit and Destroy (pelo menos no Rails, o MVC é semelhante). Por padrão, esses "

O layout dos diretórios e arquivos é significativo no MVC. Por exemplo, no ASP.NET MVC, o método Index para um objeto "Book" provavelmente terá apenas uma linha: "Return View ();" Através da magia do MVC, isso enviará o modelo de livro para a página "/View/Books/Index.aspx", onde você encontrará o código para exibir os livros. A abordagem do Rails é semelhante, embora a lógica seja um pouco mais explícita e menos "mágica". Uma página Visualizar em um aplicativo MVC geralmente é mais simples que uma página de Formulários da Web, porque eles não precisam se preocupar tanto com roteamento, lógica comercial ou manipulação de dados.

Comparação

As vantagens do MVC giram em torno de uma separação clara de preocupações e um modelo mais limpo, mais centrado em HTML / CSS / AJAX / Javascript, para produzir sua saída. Isso aprimora a capacidade de teste, fornece um design mais padronizado e abre as portas para um site mais "Web 2.0".

No entanto, existem algumas desvantagens significativas também.

Primeiro, embora seja fácil obter um site de demonstração, o modelo de arquitetura geral tem uma curva de aprendizado significativa. Quando eles dizem "Convenção sobre configuração", parece bom - até você perceber que tem um livro de convenções para aprender. Além disso, é muitas vezes uma enlouquecedora pouco para descobrir o que está acontecendo porque você está contando com a magia em vez de chamadas explícitas. Por exemplo, esse "Return View ();" ligar acima? A mesma chamada exata pode ser encontrada em outras ações, mas elas vão para lugares diferentes. Se você entende a convenção MVCentão você sabe por que isso é feito. No entanto, certamente não se qualifica como um exemplo de boa nomeação ou código facilmente compreensível e é muito mais difícil para os novos desenvolvedores entender do que os Web Forms (isso não é apenas uma opinião: eu tive um estagiário de verão aprendendo Web Forms no ano passado e MVC este ano e as diferenças de produtividade foram pronunciadas - a favor dos Web Forms). Aliás, o Rails é um pouco melhor nesse aspecto, embora o Ruby on Rails possua métodos denominados dinamicamente, que também precisam ser acostumados.

Segundo, o MVC assume implicitamente que você está construindo um site clássico no estilo CRUD. As decisões de arquitetura e, especialmente, os geradores de código são todos criados para suportar esse tipo de aplicativo da web. Se você estiver criando um aplicativo CRUD e quiser adotar uma arquitetura comprovada (ou simplesmente não gostar do design da arquitetura), provavelmente deverá considerar o MVC. No entanto, se você estiver fazendo mais do que CRUD e / ou for razoavelmente competente com a arquitetura, o MVC poderá parecer uma camisa de força até que você realmente domine o modelo de roteamento subjacente (que é consideravelmente mais complexo do que simplesmente rotear em um aplicativo WebForms). Mesmo assim, senti que estava sempre lutando contra o modelo e preocupado com resultados inesperados.

Terceiro, se você não se importa com o Linq (porque tem medo de que o Linq-to-SQL desapareça ou porque você acha que o Linq-to-Entities é ridiculamente superproduzido e com pouca energia), então você também não quer seguir esse caminho, já que as ferramentas de andaime do ASP.NET MVC são criadas em torno do Linq (esse foi o assassino para mim). O modelo de dados do Rails também é bastante desajeitado em comparação com o que você pode obter se tiver experiência em SQL (e especialmente se você for versado em TSQL e procedimentos armazenados!).

Quarto, os proponentes do MVC geralmente apontam que as visualizações do MVC estão mais próximas do modelo HTML / CSS / AJAX da web. Por exemplo, "HTML Helpers" - as pequenas chamadas de código em sua página vew que trocam conteúdo e as colocam em controles HTML - são muito mais fáceis de integrar com Javascript do que controles Web Forms. No entanto, o ASP.NET 4.0 introduz a capacidade de nomear seus controles e, assim, elimina amplamente essa vantagem.

Em quinto lugar, os puristas do MVC costumam ridicularizar o Viewstate. Em alguns casos, eles têm razão em fazê-lo. No entanto, o Viewstate também pode ser uma ótima ferramenta e um benefício para a produtividade. A título de comparação, lidar com o Viewstate é muito mais fácil do que tentar integrar controles da web de terceiros em um aplicativo MVC. Embora a integração de controle possa ficar mais fácil para o MVC, todos os esforços atuais que vi sofrem com a necessidade de criar código (um tanto grody) para vincular esses controles à classe Controller da visualização (ou seja, para contornar o modelo MVC )

Conclusões

Eu gosto do desenvolvimento do MVC de várias maneiras (embora eu prefira o Rails ao ASP.NET MVC por muito tempo). Eu também acho que é importante não cair na armadilha de pensar que o ASP.NET MVC é um "antipadrão" do ASP.NET Web Forms. Eles são diferentes, mas não completamente alienígenas e certamente há espaço para ambos.

No entanto, prefiro o desenvolvimento de Web Forms porque, para a maioria das tarefas , é simplesmente mais fácil realizar as tarefas (a exceção é a geração de um conjunto de formulários CRUD). O MVC também parece sofrer, em certa medida, com um excesso de teoria. De fato, observe as muitas perguntas feitas aqui no SO por pessoas que conhecem o ASP.NET orientado a página, mas que estão tentando o MVC. Sem exceção, há muito ranger de dentes, pois os desenvolvedores descobrem que não podem executar tarefas básicas sem pular os aros ou suportar uma enorme curva de aprendizado. Isto é o que faz Web Forms superiores a MVC em meu livro: MVC faz você pagar um preço mundo real , a fim de ganhar um pouco mais de capacidade de teste ou, pior ainda, simplesmente ser visto como legal porque você está usando otecnologia mais recente.

Atualização: Fui muito criticado na seção de comentários - alguns deles bastante justos. Assim, passei vários meses aprendendo Rails e ASP.NET MVC apenas para garantir que eu realmente não estivesse perdendo a próxima grande novidade! Obviamente, isso também ajuda a garantir que eu forneça uma resposta equilibrada e apropriada à pergunta. Você deve saber que a resposta acima é uma reescrita importante da minha resposta inicial, caso os comentários pareçam estar fora de sincronia.

Enquanto eu olhava mais de perto para o MVC, pensei, por um tempo, que acabaria com uma grande mea culpa. No final, concluí que, embora eu ache que precisamos gastar muito mais energia na arquitetura e na testabilidade de formulários da Web, o MVC realmente não responde à chamada para mim. Então, um sincero "obrigado" às pessoas que forneceram críticas inteligentes à minha resposta inicial.

Quanto àqueles que viram isso como uma batalha religiosa e que incansavelmente projetaram inundações com votos negativos, não entendo por que você se incomoda (mais de 20 votos negativos em segundos um do outro em várias ocasiões certamente não é normal). Se você está lendo esta resposta e se perguntando se há algo realmente "errado" na minha resposta, uma vez que a pontuação é muito menor do que algumas das outras respostas, tenha certeza de que ela diz mais sobre algumas pessoas que discordam do que o senso geral de a comunidade (no geral, essa foi votada mais de 100 vezes).

O fato é que muitos desenvolvedores não se importam com o MVC e, de fato, essa não é uma visão minoritária (mesmo no MS, como os blogs parecem indicar).

O MVC oferece a você mais controle sobre sua saída e, com esse controle, aumenta o risco de escrever HTML, tags de sopa, etc. mal projetados, etc.

Mas, ao mesmo tempo, você tem várias novas opções que não tinha antes ...

1. Mais controle sobre a página e os elementos dentro da página
2. Menos "lixo" na sua saída, como o ViewState ou IDs excessivamente longos em elementos (não me interpretem mal, eu gosto do ViewState)
3. Melhor capacidade de programar do lado do cliente com Javascript (aplicativos da Web 2.0 para alguém?)
4. Não apenas o MVC, mas o JsonResult é liso ...

Agora, isso não quer dizer que você não possa fazer nada com o WebForms, mas o MVC facilita.

Ainda uso WebForms para quando preciso criar rapidamente um aplicativo Web, pois posso tirar proveito dos controles do servidor etc. O WebForms oculta todos os detalhes das tags de entrada e dos botões de envio.

WebForms e MVC são capazes de lixo absoluto se você for descuidado. Como sempre, um planejamento cuidadoso e um design bem elaborado resultarão em um aplicativo de qualidade, independentemente de ser MVC ou WebForms.

[Atualizar]

Se houver algum consolo, o MVC é apenas uma nova tecnologia em evolução da Microsoft. Houve muitas postagens nas quais os WebForms não apenas permanecerão, mas continuarão sendo desenvolvidos para ...

http://haacked.com

http://www.misfitgeek.com

http://rachelappel.com

... e assim por diante...

Para aqueles preocupados com o caminho que o MVC está tomando, eu sugiro que dê aos "seus caras" seus comentários. Eles parecem estar ouvindo até agora!

A maioria das objeções ao ASP.NET MVC parece centrada nas exibições, que são um dos bits mais "opcionais" e modulares da arquitetura. NVelocity , NHaml , Spark , XSLT e outros mecanismos de visualização podem ser facilmente trocados (e está ficando mais fácil a cada versão). Muitos deles têm sintaxe MUITO mais concisa para executar a lógica e formatação da apresentação, enquanto ainda dão controle completo sobre o HTML emitido.

Além disso, quase todas as críticas parecem se resumir à marcação <%%> nas visualizações padrão e o quão "feio" é. Essa opinião geralmente está enraizada no uso da abordagem WebForms, que apenas move a maior parte da feiura clássica do ASP para o arquivo code-behind.

Mesmo sem fazer o code-behind "errado", você tem coisas como OnItemDataBound in Repeater, que é tão esteticamente feio, mesmo que de maneira diferente, como "tag soup". Um loop foreach pode ser muito mais fácil de ler, mesmo com incorporação variável na saída desse loop, principalmente se você vier ao MVC de outras tecnologias que não sejam do ASP.NET. É preciso muito menos Google-fu para entender o loop foreach do que descobrir que a maneira de modificar esse campo em seu repetidor é mexer com OnItemDataBound (e o ninho de ratos para verificar se é o elemento certo a ser alterado).

O maior problema com o "espaguete" baseado em sopa de tags ASP era mais sobre empurrar coisas como conexões de banco de dados entre o HTML.

O fato de isso acontecer com <%%> é apenas uma correlação com a natureza do espaguete do ASP clássico, não com a causa. Se você mantiver sua lógica de exibição em HTML / CSS / Javascript e a lógica mínima necessária para fazer a apresentação , o restante será a sintaxe.

Ao comparar um pouco de funcionalidade às WebForms, inclua todo o C # gerado pelo designer e o C # por trás do código junto com o código .aspx para garantir que a solução MVC realmente não seja, de fato, muito mais simples .

Quando combinado com o uso criterioso de visualizações parciais para bits repetíveis da lógica de apresentação, pode realmente ser agradável e elegante.

Pessoalmente, desejo que grande parte do conteúdo do tutorial inicial se concentre mais nesse objetivo, do que quase exclusivamente na inversão de controle, conduzida por teste, etc. opor-se à "tag soup".

Independentemente disso, esta é uma plataforma que ainda está na versão beta. Apesar disso, está ficando MUITO mais implantação e desenvolvedores que não são da Microsoft construindo coisas reais com ele do que a maioria das tecnologias beta da Microsoft. Dessa forma, o burburinho tende a parecer mais avançado do que a infraestrutura em torno dele (documentação, padrões de orientação etc.). Ser genuinamente utilizável neste momento apenas amplifica esse efeito.

<% if (Model.PreviousPost || Model.NextPost) { %>
    <div class="pager">
        <% if (Model.PreviousPost) { %>
            <span><% Html.ActionLink("<< " + Model.PreviousPost.Subject, "view")); %></span>
        <% } if (Model.NextPost) { %>
            <span><% Html.ActionLink(Model.NextPost.Subject + " >>", "view")); %></span>
        <% } %>
    </div>
<% } %>

Você pode fazer outra postagem perguntando como fazer isso sem incluir o CSS incorporado.

NOTA: ViewData.Model torna-se modelo na próxima versão.

E com a ajuda de um controle de usuário, isso se tornaria

<% Html.RenderPartial("Pager", Model.PagerData) %>

onde PagerData é inicializado por meio de um construtor anônimo no manipulador de ações.

edit: Estou curioso para saber como seria a implementação do seu formulário da Web para esse problema.

Não sei em que momento as pessoas deixaram de se importar com seu código.

HTML é a exibição mais pública do seu trabalho; existem muitos desenvolvedores por aí que usam o bloco de notas, o bloco de notas ++ e outros editores de texto sem formatação para criar muitos sites.

O MVC trata de recuperar o controle de formulários da Web, trabalhar em um ambiente sem estado e implementar o padrão de design do Model View Controller sem todo o trabalho extra que normalmente ocorre na implementação desse padrão.

Se você deseja controle, código limpo e uso de padrões de design do MVC, é para você. Se você não gosta de trabalhar com marcação, não se preocupe com o quão malformada sua marcação é, use ASP.Net Web Forms.

Se você não gostar, definitivamente vai fazer o mesmo trabalho na marcação.

EDIÇÃO I Também devo declarar que os Web Forms e o MVC têm seu lugar, de maneira alguma afirmei que um era melhor que o outro, apenas que cada MVC tem a força de recuperar o controle sobre a marcação.

Eu acho que você está perdendo algumas coisas. Primeiro, não há necessidade do Response.Write, você pode usar as <%= %>tags. Segundo, você pode escrever suas próprias extensões HtmlHelper para executar ações comuns. Terceiro, um pouco de formatação ajuda muito. Quarto, tudo isso provavelmente estaria preso em um controle de usuário para ser compartilhado entre várias visualizações diferentes e, portanto, a marcação geral na visualização principal é mais limpa.

Eu garanto que a marcação ainda não é tão clara quanto se gostaria, mas pode ser consideravelmente limpa com o uso de algumas variáveis ​​temporárias.

Agora, isso não é tão ruim e seria ainda melhor se eu não tivesse que formatá-lo para SO.

 <%
    var PreviousPost = ViewData.Model.PreviousPost;
    var NextPost = ViewData.Model.NextPost;

    // Display the "Next and Previous" links
    if (PreviousPost != null || NextPost != null)
    {
  %>

 <div>

        <%= PreviousPost == null
                ? string.Empty
                : Html.ActionLinkSpan("<< " + PreviousPost.Subject,
                                "view",
                                new { id = PreviousPost.Id },
                                new { style = "float: left;" } ) %>
          <%= NextPost == null
                ? string.Empty
                : Html.ActionLinkSpan( NextPost.Subject + " >>",
                                   "view",
                                    new { id = NextPost.Id },
                                    new { style = "float: right;" } ) %>

  <div style="clear: both;" />
  </div>

  <% } %>

O grande problema do MVC é que ele é uma estrutura conceitual que já existe há muito tempo e provou ser uma maneira produtiva e poderosa de criar aplicativos da Web e aplicativos de estação de trabalho que escalam horizontal e verticalmente. Ele volta diretamente para o Alto e Smalltalk. A Microsoft está atrasada para a festa. O que temos agora com o ASP.NET MVC é realmente primitivo, porque há muito o que fazer; mas caramba, eles estão lançando novos lançamentos rapidamente e furiosamente.

Qual foi o grande problema com Ruby on Rails? O Rails é MVC. Os desenvolvedores estão se convertendo porque, de boca em boca, tornou-se o caminho para os programadores serem produtivos.

É um grande negócio; O MVC e o endosso implícito do jQuery são pontos de inflexão para a Microsoft aceitar que a neutralidade de plataforma é crítica. E o que é neutro, é que, diferentemente dos Web Forms, a Microsoft não pode prendê-lo conceitualmente. Você pode pegar todo o seu código C # e reimplementá-lo completamente em outro idioma (por exemplo, PHP ou java - o nome dele) porque é o conceito MVC que é portátil, não o código em si. (E pense em como é grande o fato de você poder ter seu design e implementá-lo como um aplicativo de estação de trabalho com poucas alterações de código e nenhuma alteração de design. Tente isso com Web Forms.)

A Microsoft decidiu que o Web Forms não será o próximo VB6.

Por favor, dê uma olhada no post de Rob Conery. Acho que vou apenas dizer: você deve aprender MVC.

As duas principais vantagens da estrutura do ASP.NET MVC sobre formulários da Web são:

1. Testabilidade - A interface do usuário e os eventos nos formulários da web são quase impossíveis de testar. Com o ASP.NET MVC, as ações do controlador de teste de unidade e as visualizações que eles renderizam são fáceis. Isso tem um custo inicial de desenvolvimento, mas estudos mostraram que isso compensa a longo prazo quando chega a hora de refatorar e manter o aplicativo.
2. Melhor controle sobre o HTML renderizado - Você declara que não se importa com o HTML renderizado porque ninguém olha para ele. Essa é uma reclamação válida se esse for o único motivo para ter o HTML formatado corretamente. Existem inúmeras razões para querer HTML adequadamente formatado, incluindo: SEO, a capacidade de usar seletores de identificação com mais frequência (em css e javascript), pegadas de página menores devido à falta de viewstate e ids ridiculamente longos (ctl00_etcetcetc).

Agora, esses motivos realmente não tornam o ASP.NET MVC melhor ou pior do que os formulários da Web em preto e branco. O ASP.NET MVC tem seus pontos fortes e fracos, assim como os formulários da Web. No entanto, a maioria das reclamações sobre o ASP.NET MVC parece resultar de uma falta de entendimento sobre como usá-lo, e não de falhas reais na estrutura. O motivo pelo qual seu código não parece certo ou parece correto pode ser porque você tem vários anos de experiência em formulários da web e apenas 1-2 meses de experiência em ASP.NET MVC.

O problema aqui não é tanto que o ASP.NET MVC seja bom ou ruim, é que ele é novo e há muito pouco acordo sobre como usá-lo corretamente. O ASP.NET MVC oferece muito mais controle refinado sobre o que está ocorrendo no seu aplicativo. Isso pode facilitar ou dificultar certas tarefas, dependendo de como você as aborda.

Ei, estou lutando para mudar para o MVC também. Eu absolutamente não sou fã de renderizações clássicas de ASP e MVC, me lembrando muitos daqueles dias. No entanto, quanto mais eu uso o MVC, mais ele cresce em mim. Eu sou um cara de webforms (como muitos são) e passei os últimos anos me acostumando a trabalhar com datagrids, etc. Com o MVC que é retirado. As classes HTML Helper são a resposta.

Recentemente, passei 2 dias tentando descobrir a melhor maneira de adicionar paginação a uma "grade" no MVC. Agora, com os formulários da web, eu poderia fazer isso rapidamente. Mas vou dizer isso ... depois que as classes auxiliares de paginação foram criadas para o MVC, ficou extremamente simples de implementar. Para mim, ainda mais fácil do que webforms.

Dito isto, acho que o MVC será muito mais amigável ao desenvolvedor quando houver um conjunto consistente de HTML Helpers por aí. Acho que começaremos a ver uma tonelada de classes auxiliares de HTML surgindo na Web em um futuro próximo.

É engraçado, porque foi o que eu disse quando vi os webforms pela primeira vez.

Admito que ainda não recebi o asp.net MVC. Estou tentando usá-lo em um projeto paralelo que estou fazendo, mas está indo bem devagar.

Além de não ser capaz de fazer coisas tão fáceis de fazer em formulários da web, percebo a sopa de tags. Realmente parece dar um passo atrás dessa perspectiva. Continuo esperando que, à medida que aprendo, melhore.

Até agora, notei que o principal motivo para usar o MVC é obter controle total sobre o seu HTML. Também li que o asp.net MVC é capaz de atender mais páginas mais rapidamente que formulários da web e provavelmente relacionado a isso, o tamanho da página individual é menor que uma página média de formulários da web.

Realmente não me importo com a aparência do meu HTML, desde que funcione nos principais navegadores, mas me importo com a rapidez com que minhas páginas são carregadas e com a largura de banda que elas ocupam.

Embora eu concorde plenamente que essa é uma marcação feia, acho que usar a sintaxe da exibição feia para amortizar o ASP.NET MVC como um todo não é justo. A sintaxe da exibição recebeu a menor atenção da Microsoft, e espero que algo seja feito em breve.

Outras respostas discutiram os benefícios do MVC como um todo, portanto, focarei na sintaxe da exibição:

O incentivo para usar o Html.ActionLink e outros métodos que geram HTML é um passo na direção errada. Isso cheira a controles de servidor e, para mim, está resolvendo um problema que não existe. Se vamos gerar tags a partir do código, por que se preocupar em usar HTML? Podemos apenas usar o DOM ou algum outro modelo e criar nosso conteúdo no controlador. Ok, isso parece ruim, não é? Ah, sim, separação de preocupações, é por isso que temos uma visão.

Eu acho que a direção correta é tornar a sintaxe da visualização o mais semelhante possível ao HTML. Lembre-se de que um MVC bem projetado não deve apenas separar o código do conteúdo, mas também otimizar sua produção, fazendo com que pessoas especializadas em layout trabalhem nas visualizações (mesmo que não conheçam o ASP.NET) e, em seguida, mais tarde, como desenvolvedor, você pode intervir e tornar o modelo de exibição realmente dinâmico. Isso só pode ser feito se a sintaxe da exibição se parecer muito com HTML, para que o pessoal do layout possa usar o DreamWeaver ou qualquer que seja a ferramenta de layout popular atual. Você pode criar dezenas de sites ao mesmo tempo e precisar escalar dessa maneira para obter eficiência na produção. Deixe-me dar um exemplo de como eu podia ver a exibição "idioma" funcionando:

<span mvc:if="ViewData.Model.ShowPrevious" style="float: left;">
    <a mvc:inner="ViewData.Model.PreviousPost.Subject" href="view/{ViewData.Model.PreviousPost.Id}">sample previous subject</a>
</span> 
<span mvc:if="ViewData.Model.ShowNext" style="float: left;">
    <a mvc:inner="ViewData.Model.NextPost.Subject" href="view/{ViewData.Model.NextPost.Id}">sample next subject</a>
</span> 
<div mvc:if="ViewData.Model.ShowNextOrPrevious" style="clear: both;" />

Isso tem várias vantagens:

• parece melhor
• mais conciso
• sem alternância de contexto descolada entre tags HTML e <%%>
• palavras-chave fáceis de entender que são auto-explicativas (mesmo um não programador poderia fazer isso - bom para paralelização)
• o máximo possível de lógica voltada para o controlador (ou modelo)
• sem HTML gerado - novamente, isso torna muito fácil para alguém entrar e saber onde estilizar algo, sem ter que mexer com o HTML. métodos
• o código possui um texto de amostra que é renderizado quando você carrega a visualização como HTML simples em um navegador (novamente, bom para as pessoas de layout)

Então, o que exatamente essa sintaxe faz?

mvc: inner = "" - o que estiver entre aspas é avaliado e o HTML interno da tag é substituído pela string resultante. (Nosso texto de amostra é substituído)

mvc: outer = "" - o que estiver entre aspas é avaliado e o HTML externo da tag é substituído pela string resultante. (Mais uma vez, o texto de exemplo é substituído.)

{} - usado para inserir saída dentro de atributos, semelhante a <% =%>

mvc: if = "" - dentro do qoutes é a expressão booleana a ser avaliada. O fechamento do if é onde a tag HTML é fechada.

mvc: else

mcv: elseif = "" - ...

mvc: foreach

Agora, só posso falar por mim aqui:

OMI, se você é um obstinado (qualquer coisa), a conversão não é para você. Se você gosta de WebForms, é porque pode realizar o que precisa e esse também é o objetivo de qualquer um.

As Webforms fazem um bom trabalho abstraindo HTML do desenvolvedor . Se esse é seu objetivo, fique com os Formulários da Web. Você tem toda a maravilhosa funcionalidade "clicar e arrastar" que tornou o desenvolvimento da área de trabalho o que é hoje. Existem muitos controles incluídos (além de diversos controles de terceiros) que podem gerar funcionalidades diferentes. Você pode arrastar uma "grade" diretamente associada a um DataSource do seu banco de dados; ele vem com edição embutida, paginação, etc.

No momento, o ASP.NET MVC é muito limitado em termos de controles de terceiros. Então, novamente, se você gosta do Rapid Application Development, onde muitas funcionalidades estão conectadas, não deve tentar se converter.

Com tudo isso dito, é aqui que brilha o ASP.NET: - TDD. O código não é testável, disse nuff.

• Separação de preocupações. Essa é a espinha dorsal do padrão MVC. Estou perfeitamente ciente de que você pode fazer isso nos Web Forms. No entanto, eu gosto de estrutura imposta. Era muito fácil nos Web Forms misturar design e lógica. O ASP.NET MVC facilita o trabalho de diferentes membros de uma equipe em diferentes seções do aplicativo.

• Vindo de outro lugar: Meu histórico é CakePHP e Ruby on Rails. Então, está claro onde está meu preconceito. É simplesmente sobre o que você está confortável.

• Curva de Aprendizagem: Expandir no último ponto; Eu odiava a idéia de "modelar" para alterar a funcionalidade de diferentes elementos. Não gostei do fato de muito do design ter sido realizado no código por trás do arquivo. Era mais uma coisa a aprender, quando eu já estava intimamente familiarizado com HTML e CSS. Se eu quiser fazer algo em um "elemento" na página, eu uso um "div" ou "span", bato um ID nele e pronto. Nos Web Forms, eu teria que pesquisar como fazer isso.

• Estado atual do "design" da web: bibliotecas JavaScript como o jQuery estão se tornando mais comuns. A maneira como os Web Forms gerenciam seus IDs apenas dificulta a implementação (fora do Visual Studio).

• Mais separação (design): como grande parte do design está conectado aos seus controles, seria muito difícil para um designer externo (sem Web Forms) trabalhar em um projeto de Web Forms. Web Forms foi criado para ser o fim de tudo e ser tudo.

Novamente, muitos desses motivos decorrem do meu desconhecimento dos Web Forms. Um projeto de Web Forms (se criado corretamente) pode ter "a maioria" dos benefícios do ASP.NET MVC. Mas essa é a ressalva: "Se projetado corretamente". E isso é apenas algo que eu não sei fazer nos Web Forms.

Se você está fazendo um trabalho excelente em Web Forms, é eficiente e funciona para você, é aí que você deve ficar.

Basicamente, faça uma revisão rápida de ambos (tente encontrar uma fonte imparcial [boa sorte]) com uma lista de prós e contras, avalie qual deles se encaixa em seus objetivos e escolha com base nisso.

Resumindo, escolha o caminho de menor resistência e maior benefício para atingir seus objetivos. Os Web Forms são uma estrutura muito madura e só melhorarão no futuro. O ASP.NET MVC é simplesmente outra alternativa (para desenhar desenvolvedores Ruby on Rails e CakePHP, como eu: P)

Os JSPs do Java EE eram assim quando foram propostos pela primeira vez - código feio de scriptlet.

Em seguida, eles ofereceram bibliotecas de tags para torná-las mais tag-ish HTML. O problema era que qualquer um poderia escrever uma biblioteca de tags. Alguns dos resultados foram desastrosos, porque as pessoas incorporaram muita lógica (e até estilo) às bibliotecas de tags que geravam HTML.

Eu acho que a melhor solução é a JSP Standard Tag Library (JSTL). É "padrão", tag-ish HTML, e ajuda a impedir que as pessoas coloquem lógica nas páginas.

Um benefício adicional é que preserva essa linha de demarcação entre web designers e desenvolvedores. Os bons sites que eu vejo são projetados por pessoas com senso estético e design para usabilidade. Eles distribuem as páginas e o CSS e os transmitem aos desenvolvedores, que adicionam os bits de dados dinâmicos. Falando como um desenvolvedor que não tem esses presentes, acho que damos algo importante quando pedimos aos desenvolvedores que escrevam páginas da Web de sopa a nozes. O Flex e o Silverlight sofrerão o mesmo problema, porque é improvável que os designers conheçam bem o JavaScript e o AJAX.

Se o .NET tivesse um caminho semelhante ao JSTL, eu recomendaria que eles investigassem.

Apenas pensei em compartilhar como essa amostra se parece com o novo mecanismo de exibição Razor, que é o padrão desde o ASP .NET MVC 3.

@{ 
    var prevPost = ViewData.Model.PreviousPost;
    var nextPost = ViewData.Model.NextPost;
}

@if (prevPost != null || nextPost != null) {
    <div>
        @if (prevPost != null) {
            <span style="float: left;">
                @Html.ActionLink("<< " + prevPost.Subject, "view", new { id = prevPost.Id })
            </span>
        }
        @if (nextPost != null) {
            <span style="float: left;">
                @Html.ActionLink(nextPost.Subject + " >>", "view", new { id = nextPost.Id })
            </span>
        }
        <div style="clear: both;" />
    </div>
}

Algum problema com isso?
Além disso, você não deveria realmente alinhar seus estilos CSS, deveria? E por que você verifica a nulidade em três lugares, em vez de apenas dois? Um extra divraramente dói. É assim que eu faria:

<div>
    @if (prevPost != null) {
        @Html.ActionLink("<< " + prevPost.Subject, "view",
            new { id = prevPost.Id, @class = "prev-link" })
    }
    @if (nextPost != null) {
        @Html.ActionLink(nextPost.Subject + " >>", "view",
            new { id = nextPost.Id, @class = "next-link" })
    }
    <div class="clear" />
</div>

Não posso falar diretamente com o projeto ASP.NET MVC, mas, de um modo geral, as estruturas MVC passaram a dominar o desenvolvimento de aplicativos da Web porque

1. Eles oferecem uma separação formal entre operações de banco de dados, "lógica de negócios" e apresentação

2. Eles oferecem flexibilidade suficiente na visualização para permitir que os desenvolvedores ajustem seu HTML / CSS / Javascript para trabalhar em vários navegadores e versões futuras desses navegadores.

É este último pedaço que é o mais importante. Com Webforms e tecnologias semelhantes, você depende do seu fornecedor para escrever seu HTML / CSS / Javascript. É algo poderoso, mas você não tem garantia de que a versão atual dos Webforms funcionará com a próxima geração de navegadores da Web.

Esse é o poder da vista. Você obtém controle total sobre o HTML do seu aplicativo. A desvantagem é que você precisa ser disciplinado o suficiente para manter a lógica em suas visualizações no mínimo e manter o código do modelo o mais simples possível.

Então, essa é a troca. Se os Webforms estiverem funcionando para você e o MVC não estiver, continue usando os Webforms

A maior parte da minha frustração com isso é simplesmente não saber como fazer as coisas "corretamente". Desde que foi lançado como uma prévia, todos nós tivemos um tempo para analisar as coisas, mas eles estão mudando bastante. No começo, fiquei muito frustrado, mas a estrutura parece viável o suficiente para me permitir criar UIs extremamente complexas (leia-se: Javascript) rapidamente. Entendo que você pode fazer isso com os Webforms como eu fazia antes, mas foi uma grande dor na bunda tentar fazer com que tudo fosse renderizado corretamente. Muitas vezes eu acabava usando um repetidor para controlar a saída exata e acabava com muita bagunça de espaguete que você tem acima também.

Em um esforço para não ter a mesma bagunça, tenho usado uma combinação de domínio, camadas de serviço e um dto para transferir para a exibição. Coloque isso junto com o spark, um mecanismo de exibição e ele fica muito bom. Demora um pouco para configurar, mas depois que você começa, eu tenho visto um grande passo na complexidade dos meus aplicativos visualmente, mas é tão fedorento e simples de se fazer código.

Eu provavelmente não faria exatamente assim, mas aqui está o seu exemplo:

<if condition="myDtp.ShowPager">
  <div>
    <first />
    <last />
    <div style="clear: both;" />
  </div>
</if>

Isso é bastante sustentável, testável e gostoso na minha sopa de códigos.

O argumento é que o código limpo é realmente possível, mas é uma grande mudança em relação à maneira como estávamos fazendo as coisas. Eu não acho que todos gostem ainda. Eu sei que ainda estou descobrindo ...

O livro recentemente publicado por Steve Sanderson 'Pro ASP.NET MVC' [1] [2], do Apress, sugere outra alternativa - criar uma extensão HtmlHelper personalizada. A amostra dele (do capítulo 4 na página 110) usa o exemplo de uma lista paginada, mas pode ser facilmente adaptada à sua situação.

public static string PostNavigator(this HtmlHelper html, Post previous, Post next, Func<int, string> pageUrl)
{
    StringBuilder result = new StringBuilder();

    if (previous != null || next != null)
    {
        result.Append("<div>");

        if (previous != null)
        {
            result.Append(@"<span class=""left"">");
            TagBuilder link = new TagBuilder("a");
            link.MergeAttribute("href", pageUrl(previous.Id));
            link.InnerHtml = String.Format("<< {0}", html.Encode(previous.Subject));
            result.Append(link.ToString());
            result.Append("</span>");
        }

        if (next != null)
        {
            if (previous != null)
            {
                result.Append(" ");
            }

            result.Append(@"<span class=""right"">");
            TagBuilder link = new TagBuilder("a");
            link.MergeAttribute("href", pageUrl(next.Id));
            link.InnerHtml = String.Format("{0} >>", html.Encode(next.Subject));
            result.Append(link.ToString());
            result.Append("</span>");
        }

        result.Append("</div>");
    }

    return result.ToString();
}

Você poderia chamá-lo na sua opinião com código semelhante a isto:

<%= Html.PostNavigator(ViewData.Model.PreviousPost, ViewData.Model.NextPost, id => Url.Action("View", new { postId = id })) %>

[1] http://blog.codeville.net/2009/04/29/now-published-pro-aspnet-mvc-framework-apress/

[2] http://books.google.com/books?id=Xb3a1xTSfZgC

Eu estava esperando ver uma postagem de Phil Haack, mas ela não estava aqui, então apenas recorte e cole em http://blog.wekeroad.com/blog/i-spose-ill-just-say-it-you-should -learn-mvc / na seção de comentários

Haacked - 23 de abril de 2009 - Rob, você é um motim! :) Eu acho engraçado quando as pessoas escrevem código espaguete no MVC e depois dizem "olha! Espaguete!" Ei, também posso escrever código espaguete em formulários da Web! Eu posso escrever em trilhos, PHP, Java, Javascript, mas não Lisp. Mas só porque ainda não consigo escrever nada no Lisp. E quando escrevo código espaguete, não olho para o meu prato com tristeza esperando ver macarrão. O ponto que as pessoas costumam fazer ao compará-lo ao ASP clássico é que, com o ASP clássico, as pessoas tendem a misturar preocupações. As páginas teriam uma lógica de exibição com a manipulação de entrada do usuário combinada com o código do modelo e a lógica de negócios, tudo misturado em um. Era disso que se tratava o espaguete! Misturar preocupações tudo em uma grande bagunça. Com o ASP.NET MVC, se você seguir o padrão, é menos provável que o faça. Sim, você ainda pode ter um pouco de código em sua visualização, mas espero que seja tudo código de visualização. O padrão incentiva você a não inserir o código de interação do usuário. Coloque no controlador. Coloque seu código de modelo em uma classe de modelo. Lá. Sem espaguete. Agora é o O-Toro Sushi. :)

Eu também; Eu gastaria meu tempo no Silverlight em vez do ASP.NET MVC. Eu tentei o MVC 1.0 e dei uma olhada na versão mais recente do 2.0 Beta 1 alguns dias atrás.

Eu não sinto que como o ASP.NET MVC seja melhor que o formulário da web. O ponto de venda do MVC é:

1. Teste de unidade)
   
2. Separe o design (visualização) e a lógica (controlador + modelo)
   
3. Nenhum viewstate e melhor gerenciamento de ID de elemento
   
4. URL RESTful e muito mais ...

Mas o formulário da web, usando code-behind. Tema, Skin e Recurso, já são perfeitos para separar o design e a lógica.

Viewstate: o gerenciamento de identificação do cliente está chegando no ASP.NET 4.0. Estou preocupado apenas com testes de unidade, mas testes de unidade não são suficientes para me transformar em ASP.NET MVC a partir de um formulário da web.

Talvez eu possa dizer: o ASP.NET MVC não é ruim, mas o formulário da web já é suficiente.

Eu uso o MVC desde que a Preview 3 foi lançada e, embora ainda esteja com dores de crescimento, ajuda bastante na área de desenvolvimento de equipes. Tente ter três pessoas trabalhando em uma única página de formulários da web e, em seguida, você entenderá o conceito de bater com a cabeça na parede. Eu posso trabalhar com um desenvolvedor que entende os elementos de design na página de visualização e com nosso deus Linq, residente, para fazer o modelo funcionar enquanto eu coloco tudo no controlador. Eu nunca fui capaz de me desenvolver em um reino em que a separação de preocupações era tão fácil de alcançar.

Maior ponto de venda do ASP.Net MVC - StackOverflow é executado na pilha MVC.

Dito isto ... seu código é muito mais bonito do que o que normalmente faço na página de visualização. Além disso, um dos caras com quem trabalho está trabalhando para envolver o auxiliar de HTML em uma biblioteca de tags. Em vez de <% = Html.RandomFunctionHere ()%>, ele funciona como

<hh: função aleatória />

Só espero que a equipe MVC chegue a isso em algum momento, porque tenho certeza de que eles farão um trabalho melhor.

Use um padrão de fachada para agrupar toda a lógica de todos os dados que você precisa exibir e, em seguida, use-o como genérico na sua exibição e ... então, não haverá mais código-espaguete. http://en.wikipedia.org/wiki/Design_pattern_(computer_science)

Se precisar de mais ajuda, cgardner2020@gmail.com

A implementação do ASP.NET MVC é horrível. A planície do produto é uma porcaria. Eu já vi várias demos e tenho vergonha do MSFT ... Tenho certeza que os caras que o escreveram são mais espertos do que eu, mas é quase como se eles não soubessem o que é o Model-View-Controller .

As únicas pessoas que conheço que estão tentando implementar o MVC são as que gostam de experimentar coisas novas do MSFT. Nas demos que vi, o apresentador tinha um tom de desculpas ...

Sou um grande fã do MSFT, mas devo dizer que não vejo motivo para me preocupar com a implementação do MVC. Use Web Forms ou jquery para desenvolvimento web, não escolha essa abominação.

EDITAR:

A intenção do padrão de design de arquitetura Model-View-Controller é separar seu domínio da apresentação das regras de negócios. Eu usei o padrão com sucesso em todos os projetos de formulários da Web que implementei. O produto ASP.NET MVC não se presta bem ao padrão de design de arquitetura real.