ASP.NET MVC 1.0 Release Candidate (Candidata a Lançamento) Agora Disponível

Hoje nós lançamos a ASP.NET MVC 1.0 Release Candidate (RC) - candidata a lançamento. Clique aqui para fazer o download (nota: o link foi criado agora e se o mesmo não estiver funcionando, aguarde alguns minutos para que o servidor possa ser atualizado). A ASP.NET MVC 1.0 Release Candidate funciona com o Visual Studio 2008 e Visual Studio Web Developer 2008 (o qual é gratuito).

A RC de hoje é último lançamento público da ASP.NET MVC que iremos entregar antes do lançamento final da versão 1.0. Nós esperamos entregar a versão final da ASP.NET MVC 1.0 no próximo mês.

Além de correções de bugs, o build (construção) de hoje inclui vários recursos novos. Também inclui alguns refinamentos para recursos existentes com base no retorno obtido dos clientes. Por favor leia as notas de lançamento que acompanham o download da ASP.NET MVC para detalhes mais completos de todas as mudanças. As notas de lançamento incluem instruções detalhadas de como fazer o upgrade de aplicações existentes construídas com a ASP.NET MVC Beta para a versão RC.

Melhorias para as Ferramentas do Visual Studio

A RC inclui vários recursos de ferramenta novos do Visual Studio (mais e além do que os existentes na versão Beta - os quais eu não cobrirei neste post). Estes recursos incluem:

Comando para Adicionar Controlador

Você agora pode digitar Ctrl-M, Ctrl-C dentro de um projeto ASP.NET MVC, ou clicar com o botão direito na pasta do controlador /Controller e escolher o menu de contexto "Adicionar->Controlador" para criar novas classes de Controlador:

Isto fará com que uma janela de diálogo "Adicionar Controlador" apareça, a qual permitirá a você nomear o Controlador, como também opcionalmente indicar se você quer "criar" métodos CRUD comuns:

Clicando no botão "Adicionar" fará com que a classe do Controlador seja criada e adicionada no projeto:

 

Comando para Adicionar Visão

Você agora pode digitar Ctrl-M, Ctrl-V dentro de um método de ação e escolher o item do menu de contexto "Adicionar Visão" para criar novos modelos de Visão:

Isto fará com que uma janela de diálogo "Adicionar Visão" apareça, a qual permite a você nomear e criar uma nova Visão (esta é pré-populada com opções baseadas em convenções). Esta janela permite a você criar modelos de Visão "vazios", ou automaticamente gerar/criar modelos de Visão que são baseados no tipo de objeto passado para a Visão através do método de ação do Controlador. A estrutura de criação usa reflexão para criar os modelos de Visão - assim é possível criar novos modelos com base em qualquer POCO (objeto simples da CLR) passado para esta. A estrutura não depende de nenhum ORM particular ou implementação de dados.

Por exemplo, a seguir nós estamos indicando que nós queremos criar um modelo de Visão "Lista" com base na seqüência de objetos do tipo Produto que são passados através do nosso método de ação acima:

 

Clicando no botão "Adicionar" fará com que o modelo da Visão seja criado dentro do diretório \Views\Products com uma implementação de "criação" padrão:

Nós podemos então executar nossa aplicação e solicitar a URL /products dentro do nosso browser para vermos uma lista de todos os produtos retornados:

A RC vem com vários modelos para geração de código: “Vazia”, “Lista”, “Detalhes”, “Edição” e “Criação” (você pode também adicionar seus próprios modelos de geração de código - mais detalhes sobre este assunto num momento).

Por exemplo, para permitir a edição de um Produto, nós podemos implementar a versão HTTP-GET de nosso método de ação "Editar" no nosso Controlador de Produtos como a seguir e então invocar o comando "Adicionar Visão":

Dentro da janela de diálogo "Adicionar Visão" nós podemos indicar que estamos passando um objeto "Produto" para nossa Visão e escolher a opção de modelo "Editar" para gerar a Visão:

Clicando no botão "Adicionar" fará com que um modelo de Visão "Editar" seja criado com a implementação de geração de código padrão dentro do diretório \Views\Products\:

 

Nós podemos então executar nossa aplicação e solicitar a URL /products/edit/1 dentro do nosso browser para editar os detalhes do Produto:

 

Para salvar as mudanças da edição, nós podemos implementar a versão HTTP-POST do nosso método de ação "Editar" no nosso controlador de Produtos:

 

Repare no código acima como no caso de um erro (por exemplo: alguém entra uma string inválida para um valor numérico) nós exibimos novamente a Visão. Os modelos de "Edição" e "Criação" gerados contém os métodos de ajuda de validação HTML necessários para preservar a entrada do usuário e sinalizar elementos de entrada de dados inválidos em vermelho quando isto acontecer:

Você raramente usará um modelo de geração de código do jeito que este é criado, e geralmente terminará substituindo-o por completo. Ser capaz de obter uma implementação inicial e de maneira rápida, e ter um modelo de Visão inicial para o seu cenário de modo que você pode facilmente customizá-lo é muito útil.

Em virtude da infraestrutura de geração de modelos suportar geração de Visões para qualquer objeto POCO CLR, você pode usar este esquema para ambos os objetos do modelo de dados (incluindo aqueles mapeados com LINQ para SQL, LINQ para Entidades, nHibernate, LLBLGen Pro, SubSonic e outras implementações populares de ORM) como também criar modelos de geração com classes customizadas de Apresentação Modelo/Modelo de Visão.

Adicionando e Customizando Modelos para Geração de Código

A infraestrutura de geração de código da ASP.NET MVC é implementada usando a arquitetura nativa do Visual Studio chamada T4 (Scott Hanselman tem um bom post a respeito da T4 aqui).

Você pode customizar/sobrescrever qualquer uma das implementações dos modelos de geração de código da ASP.NET MVC. Você pode também criar modelos de geração de código adicionais (por exemplo: a opção de geração de código "Visão Maluca do ScottGu") e tê-los disponíveis como opções dentro da janelo de diálogo "Adicionar Visão"

Para customizar os modelos de geração de código em nível de abrangência de Máquina, abra a pasta C:\Arquivos de programas\Microsoft Visual Studio 9.0\Common7\IDE\ItemTemplates\CSharp\Web\MVC\CodeTemplates”:

 

A sub-pasta "AddController" contém os modelos de geração de código para a janela de diálogo "Adicionar Controlador". A sub-pasta "AddView" contém os modelos de geração de código para a janela de diálogo "Adicionar Visão"

Os modelos para geração de código exibidos dentro da janela de diálogo "Adicionar Visão" são simplesmente arquivos de texto que possuem a extensão ".tt" para o nome do arquivo. Estes arquivos de texto ".tt" contêm código C# ou VB que é executado quando o modelo é selecionado.

Você pode abrir e editar qualquer um dos arquivos existentes para customizar o comportamento padrão da geração de código. Você pode também adicionar novos arquivos de modelo ".tt" – igual ao que eu fiz acima com o arquivo  “Scott Crazy Look.tt”. Quando você adiciona um novo arquivo de modelo, a janela de diálogo "Adicionar Visão" será atualizada para automaticamente incluir o novo modelo na lista de opções de geração de código disponíveis:

Além de customizar/adicionar arquivos de modelo no nível da máquina, você pode também adicionar/sobrescrever os mesmos no nível de projeto. Isto permite que você adicione os modelos no repositório, facilitando assim a disponibilização dos mesmos para todo o time de desenvolvimento.

Você pode customizar os modelos de geração de código no nível de projeto adicionando a pasta "CodeTemplates" dentro do seu projeto. Você pode então ter sub-pastas "AddController" e "AddView" dentro desta pasta pai:

 

Você pode sobrescrever qualquer modelo do nível de máquina simplesmente adicionando um arquivo ".tt" com o mesmo nome do projeto. Por exemplo, acima nós estamos sobrescrevendo o modelo de geração de código padrão "Controller.tt" usado nos cenários "Adicionar Controlador".

Você pode adicionar novos arquivos de modelo de geração de código para Visões na lista colocando-os dentro da pasta "AddView". Por exemplo, acima nós adicionamos um novo modelo chamado "Yet Another Crazy Look.tt" dentro do nosso projeto. Quando nós usarmos a janela de diálogo "Adicionar Visão" nós iremos ver uma união dos modelos definidos no nível da máquina e no projeto:

Nota: Quando você adiciona modelos ".tt" dentro da pasta \CodeTemplates, tenha certeza de que você setou a propriedade "Custom Tool" de cada arquivo ".tt" para uma string vazia dentro do grid de propriedades (de outro modo você verá um erro quando tentar executar o código do modelo). Você também pode precisar fechar e abrir o projeto para limpar um erro remanescente da lista de erros. Nós publicaremos mais posts que cobrem como criar/customizar os modelos de geração de código em breve.

Ir para Controlador / Ir para Visão

A construção da RC agora suporta o recurso de navegação rápida entre Controladores e Visões dentro de seus projetos.

Quando seu cursor está dentro de um método de ação de um Controlador você pode digitar Ctrl-M, Ctrl-G para navegar rapidamente para o modelo de Visão correspondente. Você pode também executar esta mesma navegação clicando dentro de um método de ação e selecionando a opção de menu "Ir para Visão":

No exemplo acima nós usamos o comando "Ir para Visão" dentro do método de ação "Editar" da classe ProductsController. Isto fará com que o modelo de Visão \Views\Products\Edit.aspx seja aberto com o foco dentro do VS:

Dentro dos arquivos de Visão você também pode agora digitar Ctrl-M, Ctrl-G para navegar rapidamente para a classe do Controlador correspondente à Visão. Você também pode executar essa navegação clicando com o botão direito do mouse dentro do modelo de Visão e selecionando a opção do menu "Ir para Controlador":

 

Tarefas do MSBuild para Compilar Visões

Por padrão, quando você constrói um projeto ASP.NET MVC todo o código dentro do projeto é compilado, exceto o código presente dentro dos arquivos de modelos para geração de Visões. Com a ASP.NET MVC Beta você tinha que rodar sua própria tarefa do MSBuild se você quisesse compilar o código presente dentro de tais arquivos. A ASP.NET MVC RC agora inclui uma tarefa integrada que você pode usar para incluir Visões como parte do processo de compilação do projeto. Isto causará uma verificação da sintaxe do código incluído dentro de todas as Visões, páginas master (mestras) e Visões parciais da aplicação, e dará a você os erros de construção se algum problema for encontrado.

Por razões de performance nós não recomendamos rodar esta tarefa. Isto é para que seja obtida uma rápida compilação durante o desenvolvimento. Contudo, é conveniente adicionar em uma configuração de construção (por exemplo: staging (preparação) e deployment (distribuição)) e/ou para uso em servidores de Build ou CI (integração contínua). Por favor revise as notas de lançamento para os passos a serem seguidos para habilitar este recurso.

Suporte à Refatoração de Visões

Os nomes dos arquivos e pastas dentro da sub-pasta da aplicação \Views serão agora automaticamente atualizados quando você renomear a classe do Controlador ou o método de ação usando o comando de refatoração "Rename" no VS 2008. O VS 2008 irá aplicar o modelo de nomeação padrão baseado em convenções para os arquivos de Visão/pastas quando a classe do Controlador for atualizada.

Melhorias em Visões

A RC inclui um número de melhorias específicas para Visões que foram incorporadas com base no retorno obtido durante os lançamentos de pré-estréia.

Visões sem Arquivos de Code-Behind

Com base no retorno obtido nós mudamos os arquivos de Visão para que estes não tenham por padrão um arquivo de code-behind. Esta mudança ajuda a reforçar o propósito das Visões em uma aplicação MVC (as quais são planejadas para lidar puramente com renderização e não para conter qualquer código relacionado a não-renderização), e para muitas pessoas elimina arquivos não usados no projeto.

A RC agora adiciona suporte à sintaxe C# ou VB para herdar modelos de Visão a partir de classes base que usam genéricos. Por exemplo, a seguir nós estamos usando este recurso com o modelo de Visão Edit.aspx – cujo atributo "inherits" deriva do tipo ViewPage<Product>:

Um benefício legal de não usar um arquivo de code-behind é que você agora terá intellisense imediato dentro dos arquivos do modelo de Visão quando você adicioná-lo no projeto. Em lançamentos passados você tinha que construir/compilar imediatamente após criar uma Visão para obter intellisense para o código dentro da Visão. A RC torna o processo de adicionar e imediatamente editar uma Visão livre do toque do compilador e muito mais perfeito (sem interrupção).

Importante: Se você está fazendo o upgrade de um projeto ASP.NET MVC que foi criado com uma versão prévia, tenha certeza de seguir os passos contidos nas notas de lançamento
– o arquivo web.config dentro do diretório \Views precisa ser atualizado com algumas configurações para que a sintaxe baseada em genéricos acima possa funcionar.

Propriedade Model

Com versões anteriores da ASP.NET MVC, você acessava o modelo de objetos fortemente tipado passado para a Visão usando a propriedade ViewData.Model:

A sintaxe usada acima ainda funciona, embora agora exista também uma propriedade "Model" de nível superior na ViewPage que você pode também usar:

Esta propriedade faz a mesma coisa do exemplo de código anterior - seu benefício maior é que esta permite a você escrever o código um pouco mais concisamente. Esta permite também que você evite usar o dicionário ViewData em casos onde você quer que a Visão somente interaja com o modelo de objetos fortemente tipado passado para a mesma.

Setando o Título

O modelo padrão da master page adicionada em novos projetos ASP.NET MVC agora tem um elemento <asp:contentplaceholder/> dentro da seção <head>. Isto torna muito mais fácil para modelos de Visão controlar o elemento <title> da página HTML renderizada – e não requer que o Controlador explicitamente passe o parâmetro "title" para configurar o título (o qual era o comportamento padrão em versões prévias da ASP.NET MVC e que pensamos questionável a partir de uma perspectiva de responsabilidades).

Por exemplo, para customizar o <title> de nossa Visão "Editar" para que este inclua o nome do Produto sendo editado nós podemos agora adicionar o código a seguir em nosso arquivo Edit.aspx para usar o título diretamente do objeto do modelo sendo passado para a Visão:

 

O código acima fará com que o nosso browser renderize o título usando o nome do Produto no tempo de execução:

Além de setar o elemento <title>, você pode também usar a abordagem apresentada acima para dinamicamente adicionar elementos <head> no tempo de execução. Outro cenário comum em que esta técnica é útil é na configuração de elementos <meta/> específicos do Modelo/Visão para otimizar os motores de busca.

Métodos de Ajuda HTML/AJAX Fortemente Tipados

Uma das requisições que algumas pessoas fizeram foi a habilidade e usar sintaxe de expressão fortemente tipada (ao invés de strings) quando referenciamos o Modelo de dados usando os objetos de ajuda HTML e AJAX da Visão.

Com a versão beta da ASP.NET MVC isto não era possível porque as classes de ajuda HtmlHelper e AjaxHelper não expunham o tipo do modelo em suas assinaturas, e assim as pessoas tinham que construir seus métodos de ajuda diretamente a partir da classe base ViewPage<TModel> para atingir este objetivo.

A versão RC da ASP.NET MVC introduz novos tipos HtmlHelper<TModel> e AjaxHelper<TModel> que são expostos na classe base ViewPage<TModel>. Estes tipos agora permitem que qualquer um construa extensões de ajuda HTML e AJAX fortemente tipadas que usam sintaxe de expressão para referenciar o modelo de dados da Visão. Por exemplo:

Os métodos de extensão de ajuda HTML presentes no assembly principal da ASP.NET MVC V1 ainda usam a sintaxe baseada em strings. O assembly "MVC Futures" lançado hoje (o qual funciona com a versão RC) tem algumas implementações dos métodos de ajuda baseados na sintaxe de expressão. Nós iremos iterar nestes métodos um pouco mais e então consideraremos adicionar os mesmos no assembly principal da ASP.NET MVC no próximo lançamento.

Você pode também, é claro, adicionar os seus próprios métodos de ajuda (usando strings ou expressões fortemente tipadas). Os métodos de ajuda HTML/AJAX integrados à ASP.NET MVC podem também ser removidos (porque eles são métodos de extensão) caso você queira substituí-los ou sobrescrevê-los com os seus.

Melhorias para o Post de Formulários

A versão RC inclui várias melhorias específicas para o post de formulários:

[Bind(Prefix=””)] Não Mais Necessário em Cenários Comuns

A RC não mais requer que você explicitamente use o atributo [Bind] (ou sete seu valor de prefixo para “”) de forma a mapear os parâmetros do post do formulário que não possuem prefixos para complicar os parâmetros do método de ação.

Para ver o que isto significa, vamos implementar o cenário "Criar" para nosso ProductsController. Nós começaremos implementando a versão HTTP-GET do nosso método de ação "Criar". Nós faremos isso com o código a seguir que retorna uma Visão com base em um objeto vazio do tipo Produto:

Nós podemos então clicar com o botão direito do mouse no nosso método de ação, escolher o comando "Adicionar Visão" e gerar o modelo de visão "Criar" que é baseado em um Produto:

Veja acima como nossos métodos de ajuda Html.TexBox() estão referenciando as propriedades "ProductName" e "SupplierID" do nosso objeto Product. Isto gerará HTML igual a seguir onde os atributos da entrada "name" são “ProductName” e “SupplierID”:

Nós podemos então implementar a versão HTTP-POST do nosso método de ação "Criar". Nós teremos nosso método de ação recebendo um objeto do tipo Product como um parâmetro:

Com a ASP.NE MVC Beta nós teríamos que adicionar um atributo [Bind(Prefix=””)] na frente do nosso argumento Product acima – de outra forma a infraestrutura de binding teria somente buscado por valores de post do form com um prefixo "productToCreate" (por exemplo: productToCreate.ProductName e productToCreate.SupplierID) e não teria achado os valores enviados a partir do nosso formulário (os quais não possuem um prefixo).

Com a versão RC, os binders padrão do método de ação ainda primeiramente tentam mapear um valor de formulário productToCreate.ProductName para o objeto Produto. Se eles não encontrarem tal valor, eles agora também tentam mapear "ProductName" para o objeto Product. Isto torna cenários onde você quer passar objetos complexos para um método de ação sintaticamente limpos e menos verbosos. Você pode tirar vantagem deste recurso em momentos de mapeamento dos objetos do domínio (igual nosso objeto Product acima) como também em classes de Apresentação do Model/ViewModel (igual a classe ProductViewModel). 

Uma implementação completa do nosso método de ação Criar (incluindo entrada de dados básica e validação) pode ser igual a seguir:

Agora nossa ação Criar salvará o objeto Produto se todos os valores forem preenchidos corretamente. Quando um usuário tenta criar um Produto com valores inválidos para as propriedades do Produto (por exemplo: uma string ao invés de um valor Decimal válido), o formulário será exibido novamente e sinalizará a entrada de dados inválida em vermelho:

Melhorias na API ModelBinder

A infraestrutura de binding (ligação) do modelo de dados dentro da ASP.NET MVC RC foi fatorada para adicionarmos pontos de extensibilidade adicionais, os quais visam permitir o binding customizável e esquemas de validação. Você pode ler mais sobre estes detalhes nas notas de lançamento da ASP.NET MVC RC.

Os Binders do Modelo também podem agora ser registrados para interfaces, em adição ao suporte já existente para classes.

Suporte ao IDataErrorInfo

O binder do modelo padrão com a ASP.NET MVC agora suporta classes que implementam a interface IDataErrorInfo. Isto permite uma abordagem comum para lançar mensagens de erro de validação de modo que estas possam ser compartilhadas entre Formulários Windows, WPF e agora aplicações ASP.NET MVC.

Melhorias para Testes Unitários

A ASP.NET MVC RC inclui algumas melhorias significantes para o teste unitário:

ControllerContext alterado para não mais derivar de RequestContext

A versão RC inclui uma refatoração da classe ControllerContext que significativamente simplifica os cenários comuns de teste unitário. A classe ControllerContext não mais deriva de RequestContext e agora a mesma encapsula RequestContext e expõe esta como uma propriedade. As propriedades de ControllerContext e seus tipos derivados são agora virtuais ao invés de selados – tornando muito mais fácil criar mock objects - objetos para simular o comportamento de um ControllerContext.

Para ver como isto ajuda, vamos considerar um método de ação igual a seguir que usa ambos os objetos intrínsecos "Request" e "User":

Para testar o método de ação acima com as versões prévias da ASP.NET MVC teríamos que criar objetos para simular RequestContext e ControllerContext (com alguns construtores não óbvios que também traziam um objeto RouteData).

Com a versão RC você pode agora testar unitariamente o ControllerContext igual a seguir (usando Moq para criar um ControllerContext para nosso Controlador que nos permite simular as propriedades Request.IsAuthenticated e User.Identity).

As melhorias na refatoração feita ajudam não somente o teste das ações do Controlador – mas também ajudam a testar filtros, rotas, tipos customizáveis de actionresult, e uma variedade de outros cenários.

Testes Unitários do AccountsController (Controlador de Contas)

A modelo de projeto da ASP.NET MVC incluído na versão RC agora adiciona 25 testes unitários pré-construídos que verificam o comportamento da classe AccountController (o qual é um Controlador adicionado ao projeto por padrão para tratar cenários de login e gerenciamento de conta). Isto torna a refatoração e atualização do AccountsController mais fácil. A implementação do AccountsController também foi modificada para permitir uma integração mais fácil de sistemas de credencial baseados em Provedores não Membership.

Proteção contra Ataques do tipo Cross Site Request Forgery (CSRF)

Ataques do tipo Cross-site request forgery (CSRF) (também chamados de ataques XSRF) fazem com que usuários de um agente de browser confiável realizem ações não intencionais em um site. Estes ataques geralmente ocorrem em virtude de um usuário ainda estar logado em um outro site. Um website malicioso explora esta vulnerabilidade criando uma requisição para o site original (por exemplo: linkando para uma URL em um site legítimo com um elemento <img src=""/> no site hackeado). A requisição é feita usando o browser do usuário com o token de autenticação e credenciais do usuário. O atacante espera que a autenticação ou cookie de sessão do usuário ainda seja válido e se for, o atacante pode algumas vezes tomar ações que causam desordem no website atacado. Você pode aprender mais a respeito desta técnica destrutiva aqui.

A ASP.NET MVC agora inclui alguns ajudantes CSRF de proteção pré-construídos que podem ajudar a mitigar ataques do tipo CSRF. Por exemplo, você agora pode usar o método de ajuda Html.AntiForgeryToken() para renderizar um sinalizador de entrada escondido dentro de formulários:

Este ajudante cria um cookie HTTP e renderiza um elemento de entrada oculto no nosso formulário. Web-sites maliciosos não serão capazes de acessar ambos os valores. 

Nós podemos então aplicar um novo atributo [ValidateAntiForgeryToken] em qualquer método de ação que nós quisermos proteger:

Isto forçará a verificação da existência dos tokens apropriados, e prevenirá a execução do nosso método de ação HTTP-POST se os valores não forem condizentes (reduzindo a chance de um ataque CSRF bem sucedido).

Melhorias para o Tratamento de Arquivos

A ASP.NET MVC RC inclui várias melhorias para o tratamento de arquivos:

FileResult e o método de ajuda File()

A verão RC adiciona uma nova classe FileResult que é usada para indicar que um arquivo está sendo retornado como um ActionResult (resultado da ação) a partir de um método de ação de um Controlador. A classe base do Controlador agora também possui um conjunto de métodos de ajuda File() que tornam fácil a criação e retorno de um FileResult.

Por exemplo, vamos assumir que nós estamos tentando construir um site para gerenciamento de fotos. Nós poderíamos definir uma simples classe "Photo" igual a seguir que encapsula os detalhes sobre uma foto armazenada:

Nós poderíamos usar o novo método de ajuda File() igual a seguir para implementar um método de ação "DisplayPhoto" em um Controlador PhotoManager que poderia ser usado para renderizar a foto a partir do valor obtido do banco de dados. No código a seguir nós estamos passando para o método de ajuda File() os bytes para serem renderizados, como também o mime-type do arquivo. Se nós apontássemos um elemento <img src=""/> para a URL de nosso método de ação, o browser mostraria a foto dentro da página:

Se nós quiséssemos que um usuário final fosse capaz de fazer o download da foto para salvá-la localmente em seu computador, nós poderíamos implementar um método de ação "DownloadPhoto" igual a seguir. No código a seguir, nós estamos passando um terceiro parâmetro – o qual fará com que a ASP.NET MVC sete um header (cabeçalho) que faz com que o browser mostre uma janela de diálogo "Save As..." (Salvar Como...), a qual é pré-populada/preenchida com o nome do arquivo fornecido:

Quando um usuário clica no link que aponta para a URL /PhotoManager/DowloadPhoto/1232 ele será avisado para salvar a imagem:

Suporte ao Upload de Arquivo

 

A versão RC também inclui um binder para o modelo pré-construído para fazer o upload de arquivos e conteúdo mime multi-parte.

Por exemplo, nós poderíamos ter um <form> cujo atributo enctype esteja setado para "multipart/form-data" para quando realizarmos um post para a URL /PhotoManager/UploadPhoto. Se um elemento <input type=”file” name=”fileToUpload”/> estivesse dentro do formulário este faria com que o arquivo selecionado pelo usuário final fosse passado para nosso método de ação como um objeto HttpPostedFileBase:

Nós poderíamos então usar um objeto HttpPostedFileBase para ter acesso aos bytes do arquivo sendo transferido para o servidor em formato raw, seu mime-type e opcionalmente salvar o mesmo no banco de dados ou disco.

Melhorias para AJAX

A ASP.NET MVC RC inclui várias melhorias para AJAX:

Arquivos do Intellisense da jQuery incluídos dentro do Modelo de Projeto da ASP.NET MVC

Novos projetos ASP.NET MVC agora incluem ambas as bibliotecas padrão da jQuery (versões completa e comprimida), como também os arquivos da documentação -vsdoc para o intellisense usados pelo Visual Studio para prover um rico suporte intellisense para a jQuery (você pode aprender mais sobre isto aqui):

Isto permite um intellisense rico para o JavaScript da jQuery dentro dos blocos de script do cliente e arquivos JavaScript:

A versão RC de hoje vem com a jQuery 1.2.6. Nós estamos planejando entregar o próximo lançamento da jQuery em sua versão 1.3.1 para o lançamento final da ASP.NET MVC 1.0, e iremos incluir um arquivo JavaScript para intellisense atualizado para esta nova versão da jQuery.

Propriedade Request.IsAjaxRequest

A propriedade Request.IsAjaxRequest pode ser usada para detectar se uma requisição está sendo enviada a partir de uma chamada AJAX do lado do cliente (e é útil para cenários onde você quer degradar de maneira elegante caso o suporte AJAX não esteja habilitado). Este é um cabeçalho muito bem conhecido enviado pelas bibliotecas JavaScript tais como Prototype, jQuery e Dojo – e agora permite um modo unificado para checar por AJAX dentro de uma requisição da ASP.NET MVC.

JavaScriptResult ActionResult e método de ajuda JavaScript()

A classe base do Controlador agora tem um método de ajuda JavaScript() que retorna uma nova classe ActionResult do tipo JavaScriptResult. Isto permite o suporte ao retorno de JavaScript em formato raw que será então executado no lado do cliente pelos métodos de ajuda pré-construídos na ASP.NET MVC. Isto pode ser útil em cenários em que você quer que JavaScript condicional seja executado no cliente com base na lógica do servidor.

Sumário

Nós estamos muito excitados por estarmos na "reta final" da ASP.NET MVC V1. Por favor reporte qualquer problema que você encontre na versão RC o mais rápido possível de modo que possamos resolver tal problema para a versão final. O time planeja monitorar cuidadosamente o retorno nas próximas semanas, e assumindo que nenhum problema maior ocorra, lançaremos a versão oficial V1 no próximo mês.

Espero que ajude,

Scott

(Texto traduzido do post original por Leniel Macaferi.)

1 Comment

  • Bacana d + !
    Só não entendi qual a vantagem de usar o HtmlHelper para gerar um input, sendo que o codigo gerado é o mesmo...e alé do mais dificulta a visualização do design da página durante a sua construção...

    Abraço !

Comments have been disabled for this content.