terça-feira, 18 de novembro de 2008

Dica: Renderizando páginas HTML no ASP.NET MVC

Olá pessoal,

Nessas últimas semanas tenho feito um mergulho profundo no ASP.net MVC Beta, e confesso que estou muito entusiasmado com o resultado. Sei que cada um tem o seu gosto por paradigmas e eu não sou diferente, e nessa semana percebi que me encontrei no MVC, e posso dizer um adeus sem remorso para os WebForms.

Acho até que foi uma escolha meio tardia, tardia em função da escolha de acompanhar especificamente o MVC da Microsoft, pois talvez se tivesse experimentado o Monorail, esse adeus teria acontecido alguns meses atrás.

Por fim, recomendo este artigo do Samir Mamude . A "história" que ele conta pode representar bem o estado de espírito de uma transição.

Bom, mas vamos pra nossa dica!

Para desenvolver controllers, quase sempre você está enviando Dados e Submetendo Views, mas existem casos onde o que você quer enviar seja simples markup, HTML. Será que necessito mesmo enviar para uma ViewPage para ser processada? Hum, Não!

Até enviei um e-mail pra equipe do MVC, vamos ver o que eles respondem. Mas o que eu gostaria de colocar é que existe uma maneira talvez um pouco mais "eficiente" de exibir esses dados casos eles sejam apenas text.


Nos controllers, um dos possíveis retornos (ActionResult's) são através da propriedade Content.

public ActionResult Home()
{
return Content("Olá Mundo");
}


Até aí, tudo bem, mas você pode enviar um arquivo HTML inteiro por ele se preferir, mas seu código poderia ficar um pouco sujo, além de enfrentar problemas na separação de competências.

Então, uma alternativa interessante (O Eder achou POG :-P) , seria de criar um resource file e inserir nele todos os arquivos HTML que não necessitam de nenhum tratamento ou manipulação, ou seja, são renderizados "as is".


Dessa forma:

public ActionResult Home()
{
return Content(ContentPages.Home);
}

...e uma página HTML inteira é renderizada através de um Controller MVC. Obviamente o conceito é o mesmo para partes de uma página HTML. Talvez isso saia mais rápido do que fazer a ViewEngine processar o conteúdo de uma View, que, pelo que percebi, não difere muito de uma classe Page do WebForms em alguns aspectos.