Chad Myers e Jeremy Miller têm opiniões fortes sobre como deveria funcionar o ASP.NET MVC. Eles apresentaram essas opiniões como um conjunto de orientações no mês passado no KaizenConf. Aqui estão alguns destaques do resumo do Jeremy.
No centro de suas recomendações há uma ênfase forte sobre a limitação do poder dos Controllers. No seu design, a área de superfície dos Controllers é muito centrada nos dados de entradas e saídas sendo limitados a um único ViewModel cada. Por não expor qualquer aspecto do HttpConext, o Controller pode ser testado mais facilmente.
Não apenas os Controllers estão expostos aos artefatos HTTP, eles também devem ser livres das lógicas de negócios.
Controllers devem ser leves. O único trabalho de uma ação de Controller é traduzir o modelo nas chamadas de serviço apropriadas e para criar o modelo de objeto de saída. Todas as responsabilidades para lógicas de negócios são feitas delegando às classes de serviços non-UI. Em outras palavras, lógicas de negócio NÃO entram em um Controller.
Sim, isso está certo. Sob seu plano o MVC não é tudo, existe algo além de lidar com todos o verdadeiro trabalho de manipulação e armazenamento de dados.
Existe muito a considerar, mas nós vamos desviar dos problemas das questões HTML e JavaScript no layer View.
Marcações Server side nunca são misturadas com client side JavaScript. É a nossa opinião de que todas essas técnicas muito comuns conduzem ao código ilegível e eliminam a possibilidade de fazer o TDD no JavaScript client side. Este: callFunction(‘<%=Model.Variable%>’) não é permitido. Se os dados server side precisaem ser passados para client side JavaScript, nos faremos isso escrevendo “var something = <% =Model.Variable%>.”
A View deveria ser muito simples. Se você está usando uma declaração if/then ou uma espécie de looping de expressão, você está fazendo algo de errado. Lógica condicional pertence ao Controller ou às bibliotecas JavaScript que podem ser testadas com o QUnit. Nenhuma, ou o mínimo de, lógica na View reduz erros movendo lógica para fora do código difícil de testar para o mais fácil de testar – e sim, eu estou dizendo que o JavaScript é fácil de testar unitariamente. Tag Soup pode ser evitada. Nós tendemos a mover a construção de looping em nossa própria implementação parcial como: <%= this.RenderPartialForEachOf(m => m.Solution.Resolutions).Using<EditResolution> ()%>. Nesse bloco de código, EditResolution refere-se a um controle ASCX e m.Solutution.Resolutions é uma propriedade do tipo IList<resolution>. Esta declaração vai iterar sobre a lista e renderizar uma view parcial para cada objeto Resolution.