•  01-07-2019
  •  | 
  •  

Pergunta

Quando eu ouvi pela primeira vez sobre StackOverflow, e ouviram o que foi sendo construído em ASP.Net MVC, eu estava um pouco confuso. Pensei ASP.Net sempre foi um exemplo de uma arquitetura MVC. Você tem a página .aspx que fornece o ponto de vista, a página .aspx.vb que fornece o controlador, e você pode criar uma outra classe a ser o modelo. O processo para usar MVC em ASP.Net é descrito neste artigo Microsoft .

Então, minha pergunta é. O que é que ASP.Net MVC prever que você não seria capaz de fazer com ASP.Net regulares (mesmo já em ASP.Net 1.1)? É URLs extravagante apenas? É apenas para se gabar para MS para ser capaz de se comparar com as novas tecnologias como Ruby On Rails, e dizer: "Nós podemos fazer isso também"? Existe algo mais que ASP.Net MVC realmente fornece, em vez de um par de modelos adicionais no File-> New cardápio?

Estou provavelmente soando realmente cético e negativo agora, então eu vou parar. Mas eu realmente quero saber o que ASP.Net MVC fornece realmente. Além disso, se alguém pode me dizer por que é MVC e não na ordem das camadas de View-Controller-Model ou Modelo-Control-View dependendo se você está indo de cima para baixo, ou vice-versa, eu realmente aprecio isso também.

Editar

Além disso, é provavelmente vale a pena apontar que eu nunca realmente importava para os formulários web (controles de servidor AKA) modelo tanto. Eu só usei minimamente, e nunca no trabalho.

Foi útil?

Solução

aspx não cumpre o padrão MVC porque a página aspx (o 'view') é chamado antes o código por trás (do 'controller').

Isto significa que o controlador tem uma 'dependência duro' na vista, que é muito contra os princípios do MVC.

Um dos principais benefícios do MVC é que ele permite que você teste o seu controlador (que contém um monte de lógica) sem instanciar uma visão real. Você simplesmente não pode fazer isso no mundo .aspx.

Teste o controlador por si só é muito mais rápido do que ter que instanciar um gasoduto toda asp.net (aplicação, pedido, resposta, o estado de exibição, o estado da sessão etc).

Outras dicas

Scott Guthrie explicado neste post " ASP.NET MVC Framework "

  • Ele permite a separação limpa de preocupações, a capacidade de teste, e TDD por padrão. Todos os contratos de núcleo dentro o framework MVC são baseados Interface e facilmente mockable (inclui interface baseada IHttpRequest / IHttpResponse intrínsecos). Você pode testar a unidade aplicação sem ter que executar o Controladores de dentro de um processo ASP.NET (Tornando o teste de unidade rápido). Você pode usar qualquer framework de testes unitários você quer-fazer este teste (incluindo NUnit, MBUnit, MS teste, etc).

  • É altamente extensível e plugável. Tudo no MVC quadro é projetado para que ele possa ser facilmente substituído / personalizado (para Exemplo: Você pode, opcionalmente, o plug-in o seu próprio motor de vista, a política de roteamento, parâmetro de serialização, etc). isto também suporta o uso existente injecção de dependência e recipiente COI modelos (Windsor, Spring.Net, NHibernate, etc).

  • Ele inclui um componente de mapeamento URL muito poderosa que permite que você aplicações construir com URLs limpas. URLs não precisa ter extensões dentro deles, e são projetados para facilmente suportar SEO e RESTO-friendly nomear padrões. Por exemplo, eu poderia facilmente mapear a / products / edit / 4 URL para a ação "Editar" do classe ProductsController no meu projeto acima, ou o mapa / Blogs / ScottGu / 10-10-2007 / AlgumTopico / URL para uma ação "DisplayPost" de um BlogEngineController classe.

  • O MVC Framework suporta usando o existente ASP.NET .ASPX, .ASCX, e .Master arquivos de marcação como "vista templates"(ou seja, você pode facilmente usar recursos ASP.NET existentes como nested mestre páginas, <% =%> trechos, controles de servidor declarativas, moldes, os dados de ligao, localização, etc). Não se trata, no entanto, usar o modelo pós-back existente para interações de volta ao servidor. Em vez disso, você vai encaminhar todo o usuário final interacções a uma classe controlador em vez disso - o que ajuda a garantir a limpo separação de interesses e capacidade de teste (Isso também significa não viewstate ou página ciclo de vida, com vistas à base MVC).

  • O framework ASP.NET MVC apoia plenamente existente ASP.NET apresenta como formas / autenticação do Windows, URL autorização, de associação / funções, saída e caching de dados, gerenciamento de estado de sessão / profile, vigilância da saúde, configuração sistema, a arquitetura do provedor, etc.

Em primeiro lugar, torna-se muito fácil para criar sites testáveis ??com separações bem definidas de responsabilidade. É também muito mais fácil criar válido XHTML UIs usando o novo framework MVC.

Eu usei o segundo CTP (eu acho que eles estão em cinco agora) para começar a trabalhar em um site e, tendo criado algumas aplicações web antes, eu tenho que dizer que suas centenas de vezes melhor do que usar o controle de servidor modelo.

Os controles do servidor são muito bem quando você não sabe o que está fazendo. Como você começar a aprender sobre como as aplicações web devem funcionar, você começa a combatê-los. Eventualmente, você tem que escrever o seu próprio para superar as deficiências dos controles atuais. Seu neste ponto onde o MVC começa a brilhar. E isso não é mesmo considerando a capacidade de teste de seu site ...

Grande artigo de Dino Esposito que se destina a explicar ASP.net MVC para ASP.net webforms developpers:

http://dotnetslackers.com/articles/aspnet/AnArchitecturalViewOfTheASPNETMVCFramework.aspx

Não há mais auto-gerado html IDs !!! Qualquer um que faz qualquer tipo de javascript aprecia este fato.

ASP.Net com ele está por trás de código é quase MVC - mas não - a única grande coisa que faz não é que os codebehinds estão vinculados diretamente para o aspx - que é um grande componente do MVC . Se você está pensando dos codebehinds como o controlador - o deve ser completamente dissociada da visão. O novo .NET MVC rodadas isso - e traz um framework MVC completa. Embora existam já existentes para .NET já (ver Spring.NET).

Eu olhei através de alguns exemplos simples, como este . Eu posso tipo de ver a diferença. No entanto, eu realmente não vejo como MVC desacopla a vista do controlador. A visão ainda referências material que está no controlador. Eu ver como ele faz com que seja muito mais fácil de teste, e que pelo menos em MVC o controlador não tem qualquer conhecimento da vista. E você não teria que processar a fim de chamar métodos do controlador. Eu posso ver que é um grande salto, mesmo que à primeira vista pode não parecer muito.

Eu concordo com @Will sobre a luta controles de servidor. Eu nunca trabalhei em uma situação onde eles foram realmente utilizados, mas muitas pessoas que conheço que têm, depararam-se com algumas limitações com eles.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top