Uma aplicação simples amostra de E-Commerce
Eu vou usar um aplicativo simples loja de e-commerce para ajudar a ilustrar como o ASP.NET MVC Framework funciona. Para o post de hoje eu vou ser a implementação de um produto cenário listagem / navegação na mesma.
Especificamente, nós vamos construir uma fachada que permite que os usuários finais para procurar uma lista de categorias de produtos, quando eles visitam os / Produtos / Categorias de URL no site:
Quando um usuário clica em um hiperlink categoria de produto na página acima, eles vão navegar para um URL de listagem de produtos da categoria - Produtos / / / Lista CategoryName - que lista os produtos ativos dentro da categoria específica:
Quando um usuário clica em um produto individual, que vai navegar para um URL de detalhes do produto - / Produtos / detalhe / ProductID - que apresenta mais detalhes sobre o produto específico que selecionou:
Vamos construir todas as funcionalidades acima, usando o novo ASP.NET MVC Framework. Isto irá permitir-nos a manter uma "clara separação de interesses" entre os diferentes componentes da aplicação, e nos permitirá integrar mais facilmente testes de unidade e desenvolvimento orientado a testes.
Criando uma nova aplicação ASP.NET MVC
O ASP.NET MVC Framework inclui modelos do Visual Studio projeto que tornam mais fácil para criar uma nova aplicação web com ele. Basta selecionar o File-> item de menu New Project e escolha a opção "ASP.NET MVC Web Application" modelo para criar uma nova aplicação web usando.
Por padrão, quando você cria um novo aplicativo usando esta opção, o Visual Studio irá criar uma nova solução para você e adicionar dois projetos para ele. O primeiro projeto é um projeto web, onde você vai implementar a sua aplicação. O segundo é um projeto de teste que você pode usar para escrever testes de unidade contra ele:
Você pode usar qualquer estrutura de testes de unidade (incluindo MBUnit, NUnit, MSTest, XUnit, e outros), com o ASP.NET MVC Framework. VS 2008 Professional inclui agora built-in testando apoio do projeto para MSTest (anteriormente no VS 2005, esta exigiu um Visual Studio Team System SKU), e nosso padrão ASP.NET MVC modelo de projeto cria automaticamente um desses projetos quando você usa o VS 2008.
Também vamos ser downloads de envio modelo de projeto para MBUnit, NUnit e outras estruturas de teste de unidade, bem como, por isso, se você preferir usar aqueles vez você também vai ter uma maneira simples clique um para criar seu aplicativo e ter um projeto de teste imediatamente pronto para usar com ele.
Compreender a estrutura de pastas de um projeto
A estrutura de diretório padrão de uma aplicação ASP.NET MVC tem 3 diretórios de nível superior:
- / Controladores
- / Modelos
- / Visualizações
Como você provavelmente pode adivinhar, recomendamos colocar suas classes de Controlador debaixo do diretório / controladores, suas classes de modelo de dados abaixo do diretório / seus modelos, e seus modelos de vista debaixo de seu diretório Views /.
Enquanto o ASP.NET MVC não forçá-lo a sempre usar esta estrutura, os modelos de projeto padrão usam este padrão e recomendamos como uma maneira fácil de estruturar a sua aplicação. A menos que você tenha uma boa razão para usar um layout de arquivo alternativo, eu recomendo usar esse padrão padrão.
Mapeando URLs para classes de controlador
Na maioria dos frameworks web (ASP, PHP, JSP, ASP.NET WebForms, etc), URLs de entrada tipicamente mapear ao modelo arquivos armazenados no disco. Por exemplo, um "Products.aspx /" ou "/ products.php" URL tem tipicamente um Products.aspx subjacente ou arquivo de modelo products.php no disco que manipula processamento. Quando uma solicitação HTTP para uma aplicação web chega no servidor web, o framework web executa o código especificado pelo arquivo de modelo no disco, e este código, então é dono de manipulação do processamento do pedido. Muitas vezes, esse código usa a marcação HTML dentro do arquivo Products.aspx ou products.php para ajudar com a geração de a resposta enviada de volta para o cliente.
Frameworks MVC normalmente mapear URLs para o código do servidor de uma maneira diferente. Em vez de mapear URLs para arquivos de modelo no disco, eles ao invés de mapear URLs diretamente para as aulas. Essas classes são chamadas de "Controllers" e eles próprios processar solicitações de entrada, manipulação de entrada do usuário e interações, e execução adequada aplicação e lógica de dados com base nelas. A classe Controller, então, normalmente chamar um separado "View" componente que possui gerando a saída real HTML para a solicitação.
O ASP.NET MVC Framework inclui um mecanismo de mapeamento muito poderosa URL que fornece uma grande flexibilidade na forma como você mapear URLs para as classes Controller.Você pode usá-lo para configurar facilmente as regras de roteamento que o ASP.NET usam para avaliar URLs de entrada e escolher um controlador para executar. Você também pode, então, ter o motor de roteamento analisar automaticamente as variáveis que definem dentro da URL e têm ASP.NET automaticamente passar estes para o seu controlador como argumentos de parâmetros. Eu estarei cobrindo cenários mais avançados da URL mecanismo de roteamento em um post de blog futuro da série.
ASP.NET MVC padrão URL Routing para classes de controlador
Por padrão projetos ASP.NET MVC ter um conjunto de regras pré-configuradas de roteamento de URL que permitem facilmente começar em uma aplicação sem a necessidade de configurar explicitamente qualquer coisa. Em vez disso, você pode começar a programar usando um conjunto padrão de nome de base convenções de URL de mapeamento que são declaradas dentro da classe aplicativo ASP.NET do arquivo Global.asax criado pelo novo modelo de projeto ASP.NET MVC no Visual Studio.
A convenção de nomenclatura padrão é mapear o caminho de URL líder de uma solicitação HTTP de entrada (por exemplo: / Produtos /) para uma classe cujo nome segue o padrão URLPathController (por exemplo: por padrão uma URL liderando com / Produtos / poderia mapear para uma classe chamada Produtos Controller).
Para construir o nosso e-commerce funcionalidade de navegação do produto, vamos adicionar uma nova "ProductsController" classe ao nosso projeto (você pode usar a opção "Adicionar novo item" menu no Visual Studio para criar facilmente uma classe de controlador de um modelo):
Nossa classe ProductsController vai derivar da classe base System.Web.Mvc.Controller. Decorrente desta classe base não é necessário - mas contém alguns métodos auxiliares úteis e funcionalidades que vamos querer aproveitar mais tarde:
Assim que definir esta classe ProductsController dentro do nosso projeto, o ASP.NET MVC, por padrão, use-a para processar todas as URLs de aplicativo de entrada que começam com o "/ Produtos /" namespace URL. Isso significa que ele será automaticamente chamado para processar os "/ Produtos / Categorias", "/ Produtos / Lista / Bebidas", e "/ Products/Detail/3" URLs que vamos querer para que dentro da nossa aplicação fachada .
Em um post futuro, também vai adicionar um ShoppingCartController (para permitir que os usuários finais para gerenciar seus carrinhos de compras) e um AccountController (para permitir que os usuários finais para criar novas contas de membros no site e login / logout do mesmo). Uma vez que adicionar essas duas classes novo controlador para o nosso projeto URLs, que começam com / ShoppingCart / e / Conta / serão automaticamente encaminhadas para eles para processamento.
Nota: O ASP.NET MVC não exige que você sempre usa esse padrão de convenção de nomenclatura. A única razão para o nosso aplicativo usa isso por padrão é porque há uma regra de mapeamento que configura este que foi adicionado automaticamente à nossa classe de aplicativo ASP.NET quando criamos o novo projeto ASP.NET MVC usando o Visual Studio. Se você não gosta esta regra, ou se quiser personalizá-lo para usar um padrão diferente mapeamento URL, basta ir para a classe de aplicativo ASP.NET (no Global.asax) e mudá-lo. Eu vou cobrir como-fazer isso em um post futuro (quando eu também vou mostrar alguns dos cenários de arrefecer o motor de roteamento de URL permite).
Compreender métodos de ação do controlador
Agora que temos uma classe criada uma ProductsController em nosso projeto podemos começar a adicionar a lógica para lidar com o processamento de entrada "/ Produtos /" URLs para a aplicação.
Ao definir os nossos e-commerce casos de uso da montra no início deste post, eu disse que estávamos indo para implementar três cenários no site: 1) Navegando todas as categorias de produtos, 2) Produtos de Listagem dentro de uma categoria específica, e 3 ) Mostrando detalhes sobre um produto específico. Nós vamos usar o SEO-friendly URLs a seguir para lidar com cada um desses cenários:
| Formato URL | Comportamento | Exemplo de URL |
| / Produtos / Categorias | Procurar todas as categorias | / Produtos / Categorias |
| / Produtos / Lista / Categoria | Lista de produtos dentro de uma categoria | / Produtos / Lista / Bebidas |
| / Produtos / Detalhe / ProductID | Ver detalhes sobre um produto específico | / Products/Detail/34 |
Há um par de formas que poderíamos escrever código dentro da nossa classe ProductsController para processar esses três tipos de URLs de entrada. Uma forma seria a de substituir o "Executar" método na classe base do Controlador e escrever nosso próprio manual if / else / lógica de comutação de olhar para a URL de entrada que está sendo solicitado e, em seguida, executar a lógica apropriada para processá-lo.
Uma abordagem muito mais fácil, porém, é usar um recurso built-in do framework MVC que nos permite definir "métodos de ação" em nosso controlador, e, então, a classe base do Controlador automaticamente invocar o método de ação apropriada para executar com base no URL regras de roteamento em uso para a nossa aplicação.
Por exemplo, poderíamos acrescentar os métodos de ação do controlador abaixo de três a nossa classe ProductsController para lidar com nossos três cenários de e-commerce URL acima:
A URL regras de roteamento que estão configurados por padrão quando um novo projeto é criado tratar a URL sub-caminho que segue o nome do controlador como o nome da ação do pedido. Então, se nós recebemos um pedido de URL / Produtos / Categorias, a regra de roteamento irá tratar "Categorias", como o nome da ação, e as categorias () método será chamado para processar o pedido. Se receber um pedido de URL / Products/Detail/5, a regra de roteamento irá tratar "Detalhe", como o nome da ação, e os detalhes () método será chamado para processar o pedido, etc
Nota: O ASP.NET MVC não requer que você sempre use esta ação padrão de nomenclatura convenção. Se você quiser usar um padrão diferente mapeamento URL, basta ir para a classe de aplicativo ASP.NET (no Global.asax) e alterá-lo .
Mapeamento de parâmetros de URL para métodos de ação do controlador
Há várias maneiras de acessar os valores dos parâmetros de URL dentro dos métodos de ação do controlador de classes.
A classe base do Controlador expõe um conjunto de solicitação e resposta objetos que podem ser usados. Esses objetos têm a estrutura API exatamente como os objetos HttpRequest / HttpResponse que você já está familiarizado com no ASP.NET. A única diferença importante é que esses objetos são agora interface baseada em vez de classes seladas (especificamente: os navios com o novo framework MVC System.Web.IHttpRequest e interfaces System.Web.IHttpResponse). O benefício de ter essas interfaces ser é que agora é fácil zombar deles - que permite que o teste de unidade fácil de classes do controlador. Falarei sobre isso com mais profundidade em um post futuro.
Abaixo está um exemplo de como podemos usar a API de solicitação para recuperar manualmente um valor de querystring ID de dentro do nosso método de ação Detalhe na classe ProductsController:
O ASP.NET MVC também suporta mapeamento automaticamente valores de URL de entrada de parâmetros como argumentos de parâmetros para métodos de ação. Por padrão, se você tem um argumento de parâmetro no seu método de ação, o framework MVC vai olhar para os dados de solicitação de entrada para ver se há um valor correspondente pedido HTTP com o mesmo nome. Se houver, ele será automaticamente passá-lo como um parâmetro para o método de ação.
Por exemplo, podemos re-escrever nosso método de ação Detalhe para aproveitar este apoio e torná-lo mais limpo, como abaixo:
Além de mapear os valores dos argumentos da coleção querystring / forma de um pedido, o ASP.NET MVC também permite que você use o MVC URL infra-estrutura de mapeamento de rotas para incorporar os valores dos parâmetros dentro do núcleo próprio URL (por exemplo: em vez de / Produtos / Detalhes? id = 3, você poderia usar / Products/Detail/3).
O padrão regra de mapeamento de rota declarada quando você cria um projeto MVC novo é um com o formato: "/ [controlador] / [ação] / [id]". O que isto significa é que, se houver qualquer URL sub-caminho depois que o controlador e nomes de ação na URL, que por padrão será tratado como um parâmetro denominado "id" - e que podem ser automaticamente passado para o nosso método de ação do controlador como uma argumento de método.
Isso significa que agora podemos usar o nosso método de detalhe para também lidar com o argumento de tomar ID do caminho URL (por exemplo: / Products/Detail/3):
Eu posso usar uma abordagem semelhante para a ação de lista para que possamos passar o nome da categoria como parte do URL (por exemplo: / Produtos / Lista / bebidas). No interesse de tornar o código mais legível, fiz um tweak para as regras de roteamento de modo que em vez de ter o nome do argumento ser chamado de "id" ele será chamado de "categoria" para esta ação.
Abaixo está uma versão de nossa classe ProductsController que agora tem roteamento de URL completa e suporte parâmetro de mapeamento implementadas:
Observe acima como a ação Lista leva o parâmetro de categoria como parte da URL, e então um parâmetro de índice opcional página como uma querystring (vamos implementar paginação do lado do servidor e usar esse valor para indicar qual página de dados de categoria para exibir com o pedido).
Parâmetros opcionais em nosso framework MVC são tratadas usando argumentos de tipo anulável em métodos de ação do controlador. Como o parâmetro página em nossa ação de lista é um int anulável (que é o que? "Int" significa sintaticamente), o framework MVC ou vai passar um valor se ele estiver presente na URL - ou passar em nulo se não. Confira o meu post anterior sobre o? nulo operador coalescentes para aprender uma dica útil / truque sobre como trabalhar com tipos anuláveis que são passados como argumentos como este.
Construção de nossos objetos do modelo de dados
Temos, agora, uma classe ProductsController e três métodos de ação sobre ele pronto para processar os pedidos vindos da web. Nosso próximo passo será a construção de algumas classes que irão nos ajudar a trabalhar com o nosso banco de dados para recuperar os dados apropriados necessários para lidar com essas solicitações web.
Em um mundo MVC "modelos" são os componentes de uma aplicação que é responsável por manter o estado. Com aplicações web este estado é tipicamente persistem dentro um banco de dados (por exemplo: podemos ter um objeto produto que é utilizado para representar os dados do produto da tabela Products dentro de nosso banco de dados SQL).
O ASP.NET MVC Framework permite a utilização de qualquer padrão de acesso a dados ou quadro que você quer, a fim de recuperar e gerenciar seus modelos. Se você quiser usar ADO.NET DataSets / DataReaders (ou abstrações construídas em cima deles) que você pode. Se você preferir usar um mapeador objeto relacional (ORM) como NHibernate, LLBLGen, WilsonORMapper, LINQ to SQL / LINQ to Entities você pode perfeitamente usar as também.
Para o nosso exemplo de aplicativo de e-commerce que vou usar o LINQ built-in para o SQL ORM enviado em. Framework 3.5 e VS 2008. Você pode aprender mais sobre o LINQ to SQL a partir de minha série em curso blogue tutorial que o cobre (em particular, certifique-se de verificar o meu Part1 , Part2 , Part3 e Part4 posts).
Vou começar pelo botão direito do mouse sobre os "Modelos" sub-diretório do nosso projeto web MVC dentro do VS e escolha a opção "Adicionar novo item" a opção de adicionar um LINQ to SQL modelo. Dentro do LINQ to SQL designer de ORM vou definir três classes de modelo de dados que mapeiam para as Categorias, Produtos e Fornecedores de tabela dentro do banco de dados de exemplo Northwind do SQL Server (leia Parte 2 da minha LINQ to SQL série para aprender a fazer isso- ):
Uma vez que nós definimos a nossa LINQ para classes de modelo de dados SQL, vou então adicionar uma classe NorthwindDataContext nova parcial para o nosso diretório Modelos também:
Dentro desta classe eu vou definir métodos auxiliares poucos que encapsulam algumas expressões LINQ que podemos usar para recuperar os objetos de categoria única do nosso banco de dados, recuperar todos os objetos do produto dentro de uma categoria específica em nosso banco de dados, bem como recuperar um objeto Produto individual com base em um ProductID fornecido:
Esses métodos auxiliares irá tornar mais fácil para nós limpa recuperar os objetos do modelo de dados necessários de nossa classe ProductsController (sem ter que escrever as expressões LINQ dentro da classe Controller em si):
Temos, agora, todo o código de dados / objetos que precisa para terminar a implementação do nosso funcionalidade ProductsController.
Finalizando a implementação da nossa classe ProductsController
Controladores em uma aplicação MVC base são responsáveis por processar as solicitações de entrada, manipulação de entrada do usuário e interações, e executar a lógica de aplicação apropriada com base neles (recuperação e atualização de dados de modelos armazenados em um banco de dados, etc).
Controladores normalmente não gerar a resposta específica para um pedido de HTML. A tarefa de gerar uma resposta HTML em vez disso é de propriedade da "visão" de componentes dentro do aplicativo - que são implementados como classes separadas / modelos de controladores. Visualizações se destinam a ser focado inteiramente em encapsular lógica de apresentação, e não devem conter qualquer lógica de aplicação ou código de recuperação de dados (em vez de toda a lógica aplicativo deve ser tratado pelo Controller).
Em um típico fluxo de trabalho web MVC, métodos de ação do controlador irá lidar com a solicitação da Web de entrada, use os valores dos parâmetros de entrada para executar código de lógica de aplicativo apropriado, recuperar ou atualizar os objetos do modelo de dados de um banco de dados, e selecione um "Visualizar" para usar para processar uma resposta adequada para o interface do usuário de um navegador. Como parte de escolher a visualização adequada para tornar, o controlador explicitamente passar (como argumentos) de todos os dados e variáveis exigidas pela "Visão", a fim de por ele para tornar a resposta apropriada:
Você pode estar se perguntando - o que é o benefício de separar o controlador ea visualização como este? Porque não basta colocá-los na mesma classe? A principal motivação em particionar a aplicação como essa é para ajudar a impor a separação de sua lógica de aplicação / dados de seu código de geração de interface do usuário. Isso torna muito mais fácil de teste de unidade lógica do seu aplicativo / dados no isolamento de sua lógica de renderização UI. Ela também pode ajudar a tornar a sua aplicação mais sustentável ao longo do tempo - já que torna mais difícil para você adicionar acidentalmente aplicativo / dados lógica em seus modelos de vista.
Ao implementar os três métodos de ação do controlador de nossa classe ProductsController, vamos usar os valores dos parâmetros de entrada de URL para recuperar os objetos de modelo apropriado do nosso banco de dados, e depois escolher uma "View" componente a ser usado para renderizar uma resposta apropriada HTML. Vamos usar um do RenderView () métodos na classe base do Controlador para especificar o ponto de vista que pretende utilizar, bem como explicitamente passar os dados específicos que queremos que o Vista para usar para processar a sua resposta.
Abaixo está o resultado final da nossa implementação ProductsController:
Observe que o número de linhas de código em nossos métodos de ação acima é muito pequena (duas linhas cada). Isto é em parte porque a URL lógica de análise parâmetro é tratado inteiramente para nós pelo framework MVC (nos salvar de ter que escrever um monte de presente de código). Esta é também, em parte, porque o cenário de navegação produto é bastante simples a partir de uma perspectiva lógica de negócios (os métodos de ação são todos os cenários de exibição somente leitura).
Em geral, porém, muitas vezes você vai achar que você vai ter o que às vezes são chamados "controladores magro" - métodos significado controlador cheios de métodos de ação relativamente concisas (menos de 10 linhas de código). Isso geralmente é um bom sinal de que você limpa encapsulado lógica de dados e lógica de seu controlador consignado também.
Unidade Testando nossa ProductsController
Você pode se surpreender que o próximo passo que vamos trabalhar é para testar a nossa lógica de aplicação e funcionalidade. Você pode perguntar - como isso é possível? Nós ainda não implementamos nossos pontos de vista, e nosso aplicativo atualmente não processar uma única tag de HTML. Bem, parte do que faz uma abordagem MVC atraente é que podemos testar a unidade de controlador e da lógica do modelo de aplicações de forma totalmente independente da Vista / lógica de geração de Html. Como você verá abaixo, pode até testar esses unidade antes de criar nossos pontos de vista.
Para o teste de unidade ProductsController classe que estamos trabalhando, vamos adicionar uma ProductsControllerTest classe no projeto de teste que foi adicionado a nossa solução, por padrão, quando criamos nossa aplicação ASP.NET MVC usando o Visual Studio:
Vamos, então, definir uma unidade de teste simples que testa a ação Detalhe da nossa ProductsController:
O ASP.NET MVC foi projetado especificamente para permitir o teste de unidade fácil. Todas as APIs do núcleo e contratos dentro do quadro são interfaces e pontos de extensibilidade são fornecidos para permitir a injeção mais fácil e customização de objetos (incluindo a habilidade de usar COI recipientes como Windsor, StructureMap, Spring.NET, e ObjectBuilder). Os desenvolvedores serão capazes de usar embutido aulas simuladas, ou usar qualquer. Quadro tipo de zombaria NET para simular suas próprias versões de teste do MVC objetos relacionados.
No teste de unidade acima, você pode ver um exemplo de como podemos injetar um boneco de implementação "ViewFactory" na nossa classe ProductsController antes de chamar o Detalhe () método de ação. Ao fazer isso, estamos substituindo o ViewFactory padrão que, de outra forma lidar com criação e renderização nossa Visão. Podemos usar esta implementação ViewFactory teste para isolar o teste de apenas um comportamento de ação nossa ProductController de detalhe (e não ter que chamar o Ver-real para fazer isso). Observe como podemos usar as três instruções Assert após o Detalhe () método de ação é chamado para verificar que o comportamento correto ocorridas no seu seio (especificamente que a ação recuperou o objeto Produto correta e depois passou para a vista adequada).
Porque nós podemos zombar e simular qualquer objeto no framework MVC (incluindo IHttpRequest e objetos IHttpResponse), você não tem que executar testes de unidade no contexto de um verdadeiro servidor web. Em vez disso, podemos criar nosso ProductsController dentro de uma biblioteca de classe normal e testá-lo diretamente. Isto pode acelerar significativamente a execução de testes de unidade, bem como simplificar a configuração e execução dos mesmos.
Se usar o Visual Studio 2008 IDE, também podemos controlar facilmente o sucesso / fracasso do nosso teste é executado (esta funcionalidade é construído agora no VS 2008 Professional):
Acho que você vai descobrir que o ASP.NET MVC Framework faz testes de escrita fácil, e permite um fluxo de trabalho TDD agradável.
Prestação de UI com Vistas
Nós terminamos a implementação e teste da aplicação + lógica de dados para a seção de navegação de produtos de nossa aplicação de e-commerce. Agora precisamos implementar a interface HTML para ele.
Nós vamos fazer isso através da implementação de "Vistas" que tornam a interface do usuário apropriado usando os objetos relacionados com vista de dados que nosso método de ação ProductsController desde quando chamar o RenderView () método:
No exemplo de código acima do método RenderView de "Categorias" parâmetro é o que indica o nome do ponto de vista que deseja processar, eo segundo parâmetro é uma lista de objetos de categorias que queremos passar para a vista e que ele use como dados para gerar a interface do usuário HTML apropriado para.
O ASP.NET MVC Framework suporta a capacidade de utilizar qualquer mecanismo de modelagem para ajudar com a geração de interface de usuário (incluindo motores de templates existentes como NVelocity, Brail - assim como os novos que você escreve-se). Por padrão, o ASP.NET MVC Framework usa a página ASP.NET existente (. Aspx), Master Page (. Mestre), e UserControl apoio (. Ascx) já dentro do ASP.NET.
Nós estaremos usando o built-in ASP.NET motor vista a implementar a nossa interface do usuário de aplicativos de comércio eletrônico.
Definindo um arquivo Site.Master
Porque vamos estar construindo muitas páginas de nosso site, nós vamos começar o nosso trabalho UI pela primeira definição de uma página mestra que podemos usar para encapsular o código HTML comum layout / cromo em todo o site. Nós vamos fazer isso em um arquivo chamado "Site.Master" que vamos criar em \ Visualizações diretório \ Shared do nosso projeto:
Podemos fazer referência a uma folha de estilo CSS externa para encapsular todos os estilos para o site, e depois usar a página mestra para definir o layout geral do site, bem como identificar as regiões de espaço reservado de conteúdo onde vamos querer páginas para ser capaz de preencher página conteúdo específico. Opcionalmente podemos usar todos os novos frescos VS 2008 recursos de designer ao fazer isso (incluindo o designer de divisão de exibição HTML , CSS Criação e Nested Mestre páginas de suporte ).
Compreender o / Estrutura de diretórios Exibições
Por padrão, quando você cria um novo projeto ASP.NET MVC usando o Visual Studio, ele irá criar um "Shared" sub-diretório sob o diretório raiz "Views". Este é o local recomendado para armazenar páginas mestras, controles de usuário e pontos de vista que queremos compartilhar entre vários controladores dentro do aplicativo.
Quando a construção de pontos de vista que são específicos para um controlador individual, o padrão ASP.NET MVC convenção é para armazená-los em sub-diretórios na raiz Views \. Por padrão, o nome de uma sub-diretório deve corresponder ao nome do controlador. Por exemplo, porque a classe Controller fomos edifício é chamado de "ProductsController", vamos por loja padrão, os pontos de vista específicos de TI dentro do \ \ Produtos Visualizações sub-diretório:
Quando chamamos o método RenderView (string viewName) dentro de um controlador específico, o framework MVC automaticamente primeiro procurar um correspondente. Modelo de visão aspx ou. Ascx debaixo do \ Views \ ControllerName diretório, e se não pode encontrar um adequado ver modelo lá ele irá verificar o \ Views \ diretório compartilhado para um:
Criando uma tela de Categorias
Podemos criar o "Categorias" Ver para o nosso ProductsController dentro do Visual Studio usando o "Adicionar novo item" opção de menu no diretório Produtos e selecionando a opção "Ver MVC Page" modelo de item. Isto irá criar uma nova página aspx que pode, opcionalmente, associar nossa página principal Site.Master para pegar a aparência geral do site (e, assim como com páginas mestras que você recebe apoio de designer completo WYSIWYG).:
Ao construir aplicativos usando um padrão MVC, você quer manter o seu código Ver mais simples possível, e certifique-se de que o código View é puramente render cerca de UI. Aplicação e os dados lógica de recuperação só deve ser escrito dentro das classes Controller. Classes de controlador pode então escolher para passar os objetos de dados necessários necessários para renderizar uma visão quando chamam o seu método RenderView. Por exemplo, a seguir no método de ação Categorias de nossa classe ProductsController estamos passando uma coleção de objetos Lista de Categoria à vista Categorias:
Páginas MVC Visualização por padrão derivam da classe base System.Web.Mvc.ViewPage, que fornece uma série de métodos auxiliares MVC e propriedades específicos que podemos usar na construção de nossa interface do usuário. Uma dessas propriedades ViewPage é chamado de "ViewData", e fornece acesso aos objetos específicos da vista de dados que o controlador passados como argumentos para o RenderView () método.
De dentro de seu Ver você pode acessar o "ViewData" em qualquer forma de ligação tardia ou fortemente tipado. Se a sua visão deriva ViewPage, a propriedade ViewData será digitado como um dicionário de ligação tardia. Se a sua visão deriva dos genéricos baseados ViewPage <T> - onde T indica o tipo de objeto de dados do ViewData o controlador passa para o Vista - então a propriedade ViewData será fortemente digitado para coincidir com o mesmo tipo que o seu controlador passado dentro
Por exemplo, meus Categorias Ver código-behind classe abaixo é decorrente de ViewPage <T> - onde estou indicando que T é uma lista de objetos Categoria:
Isso significa que eu tenho a verificação de tipo de segurança, intellisense, e de compilação em tempo integral dentro do meu código Ver ao trabalhar contra os ProductsController.Categories () fornecidos Lista <Category> ViewData:
Tornar nosso Ver Categorias:
Se você se lembrar das imagens no início deste post, queremos apresentar uma lista de categorias de produtos dentro da nossa visão Categorias:
Eu posso escrever esse código HTML geração de interface do usuário em uma de duas formas dentro de minha implementação Ver Categorias: 1) Usando o código embutido dentro do aspx, ou 2) Usando controles do servidor dentro do aspx e ligação de dados do meu código por trás..
Prestação de Abordagem 1: Usando o código embutido
Páginas ASP.NET, controles de usuário e Mestre de apoio hoje Páginas <%%> e <% =%> sintaxe para incorporar código de processamento dentro de marcação HTML. Nós poderíamos usar essa técnica dentro de nossas Categorias Vista para facilmente escrever um loop foreach que gera uma lista de categorias com marcas HTML:
VS 2008 fornece intellisense código completo dentro do editor de código para VB e C #. Isso significa que nós vamos chegar intellisense contra nossos objetos categoria de modelo passados para o Vista:
VS 2008 também fornece suporte completo para depurador de código embutido também (o que nos permite definir pontos de interrupção e dinamicamente inspecionar qualquer coisa no Vista com o depurador):
Prestação de Abordagem 2: Usando controles do lado do servidor
Páginas ASP.NET, controles de usuário e páginas mestras também suporta a capacidade de usar controles de servidor declarativas para encapsular geração de interface de usuário HTML.Em vez de usar código embutido como acima, podemos usar o controle <asp:listview> novo Framework 3.5. gerar nossa UI lista com marcadores em vez disso:
Observe acima como o controle ListView incorpora tanto a prestação de uma lista de valores, bem como lida com o cenário em que não há itens estão na lista (o <EmptyDataTemplate> nos poupa de ter que escrever uma declaração if / else na marcação). Poderíamos, então, vincular nossa lista de objetos de categoria para o controle listview usando o código-behind código como abaixo:
Importante: Em um mundo MVC só queremos colocar lógica de renderização na classe nossa Ver o code-behind (e não qualquer lógica de aplicativo ou dados). Observe acima como a única lógica que temos é a de atribuir a coleção ViewData rigidez de tipos de objetos de categoria para o controle ListView. Nossa classe Controller ProductsController é o que realmente recupera a lista de categorias do banco de dados - e não o Vista.
Esta versão do servidor de controle ListView do nosso modelo de visão irá gerar o código HTML exatamente como a nossa versão de código in-line. Porque não temos um controle <form runat="server"> na página, não viewstate, valores de ID ou de outra marcação será emitido. Apenas puro CSS amigável HTML:
Método Html.ActionLink
Uma das coisas que você deve ter percebido, tanto na linha de código e as versões do servidor de controle dos trechos de código Visualização acima são chamadas para um método Html.ActionLink:
O objeto Html é uma propriedade auxiliar na classe base ViewPage, eo método ActionLink é um auxiliar no que a torna fácil de gerar dinamicamente hiperlinks HTML link para métodos de ação em controladores. Se você olhar para a imagem de saída HTML na seção acima, você pode ver alguma saída HTML exemplo gerado por este método:
<a Bebidas href="http://weblogs.asp.net/Products/List/Beverages"> </ a>
A assinatura do método auxiliar Html.ActionLink eu estou usando é assim:
ActionLink corda (string texto valores, objeto);
O primeiro argumento representa o conteúdo interno do hiperlink para render (por exemplo: texto <a> vai aqui </ a>). O segundo argumento é um objeto anônimo que representa uma seqüência de valores de usar para ajudar a gerar a URL (você pode pensar nisso como uma forma mais limpa para gerar dicionários ). Eu vou entrar em mais detalhes sobre como exatamente isso funciona em um post futuro que cobre o motor de roteamento de URL. O resumo curto, porém, é que você pode usar o sistema de roteamento de URL tanto para processar URLs de entrada, bem como para gerar URLs que você pode emitir em HTML de saída. Se temos uma regra de roteamento como esta:
/ <controller> / <action> / <categoria>
E então escrever este código dentro de uma View ProductController da Categoria:
<% = Html.ActionLink ("Clique em mim ver Bebidas", new {action = "Lista", categoria = "Bebidas"}%>
O método ActionLink irá usar as regras de mapeamento de URL do seu aplicativo para trocar em seus parâmetros e gerar esta saída:
href="http://weblogs.asp.net/Products/List/Beverages"> <a Clique-me para ver Bebidas </ a>
Isto torna mais fácil dentro de seu aplicativo para gerar URLs e AJAX callbacks para seus controladores. Isso também significa que você pode atualizar suas regras de roteamento de URL em um lugar e ter o código de toda a sua aplicação automaticamente pegar as mudanças para o processamento URL de entrada e geração de URL de saída.
Nota Importante : Para ajudar a reforçar a capacidade de teste, o quadro hoje MVC não suporta eventos de postagem diretamente para controles de servidor dentro de seus pontos de vista.Em vez disso, as aplicações ASP.NET MVC gerar hiperlink e AJAX callbacks para ações do controlador - e então usar Visualizações (e qualquer servidor controla dentro deles) apenas para processar a saída. Isso ajuda a garantir que a sua lógica de vista permanece mínimo e exclusivamente em renderização, e que você pode facilmente unidade testar suas classes de Controlador e verificar todo o comportamento lógica de aplicação e de dados independente de seus pontos de vista. Vou escrever mais sobre isso no futuro.
Código fonte do projeto disponivel no link: http://adf.ly/e8kV0
Código fonte do projeto disponivel no link: http://adf.ly/e8kV0
como faço para ler esta publicação?
ResponderExcluirClica no link ali no meio meu velho!!
Excluir