2011-11-12 17 views
8

Estoy mirando el motor Razor y me pregunto cómo es "diferente" en comparación con la implementación clásica inicial de ASP donde estaban el código del lado del servidor y el front-end la misma página.Está usando Razor como volver al clásico asp

¿Por qué debería importarme Razor?

+0

Posible duplicado de este hilo http://stackoverflow.com/questions/558002/asp-net-mvc-classic-asp-with-net-class-library-really – Chandermani

+0

@Chandermani - Eso es sobre ASP.Net MVC no Maquinilla de afeitar. – klabranche

+1

@klabranche el motor de vista no importa, la preocupación aquí es entremezclar la interfaz de usuario y el código del lado del servidor. – Chandermani

Respuesta

7

En ASP clásico, solía tener negocio código en su archivo ("Obtener material de la base de datos y actuar en consecuencia").

En ASP.net MVC, independientemente de si utiliza ASPX o Razor View Engine, se trata de View Logic. Cosas como "Tengo 20 empleados, muéstralos en una tabla" o "Si este número es negativo, muéstralo en rojo en lugar de negro".

La lógica de negocio está en los controladores y más bajo. Luego, el controlador pasa los datos comerciales a la vista a través de un modelo de vista. La Vista solo tiene código que lo muestra, lo que generalmente es trivial pero puede tener algunas ramas lógicas propias ("Mostrar fechas en la configuración regional de usuarios" o "Mostrar empleados masculinos y femeninos en tablas separadas")

Usted puede cometer el error de poner la lógica comercial aquí. Digamos, los empleados contratados antes de 2008 son elegibles para un Certificado de Lealtad. Entonces, su tabla tiene una columna "Certificado de impresión" que solo se muestra para estos. El enfoque simple, pero mal es poner una sentencia if-:

@if(employee.HireYear <= 2008) { 
    Html.ActionLink("Print Certificate","Certificate","Cheese", 
     new { id = employee.Id }, null); 
} 

Esto funciona, pero es erróneo porque ahora la vista contiene la lógica de negocio. El enfoque correcto es agregar un nuevo campo bool al ViewModel. Dado que contiene un IList<Employee> en este ejemplo, significa crear otra clase EmployeeWithCertificateEligibility, o mejor, tener listas separadas para los empleados elegibles y no elegibles. Sin embargo, es algo común tener un derrame de lógica de negocios en la vista, a veces en forma de un método de extensión HtmlHelper.

Editar: Lo comparas con la "implementación clásica inicial de asp". Eso puede significar tres cosas: Classic ASP, ASP.net WebForms o ASP.net MVC con el motor de visualización WebForms/ASPX. Mi ejemplo se refiere a los dos primeros casos. Si ya conoces todo el material de MVC y te preguntas sobre las diferencias entre Webforms y Razor View Engine: Conceptualmente son lo mismo, Razor es mucho menos detallado y más limpio.

6

Así es como lo usa.

La principal ventaja que veo de Razor es que permite que un desarrollador sea más compacto y expresivo con su diseño similar a Spark o NHaml.

En lugar de escribir:

<% Foreach(var x....) { %> 
<li><%=x.PropertyName%> (<%=x.AnotherProperty%>)</li> 
<% } </%> 

Se puede escribir de una manera más fluida:

@foreach(var x...) { 
<li>@x.PropertyName (@x.AnotherProperty)</li> 
} 

Es más fácil de leer, fluye más bien y en casos más complicados pueden ser menos código.

La realidad es que Razor e incluso los clásicos WebForms pueden combinar su código y marcado juntos.

Depende del codificador saber cuándo es algo bueno o malo hacer.

Es malo rociar un poco de lógica en la vista. Talvez no. ¿Es malo escribir toda tu lógica en la vista? Probablemente sí. ¿Qué pasa si se trata de una simple aplicación de dos páginas frente a una aplicación empresarial ... Creo que entiendes? :-)

Here's a nice write up y another de algunas de las cosas que Razor puede hacer que también lo hacen más potente que el clásico ASP.

Un pensamiento de despedida. Razor es un motor de visualización. Está diseñado para facilitar nuestro trabajo al crear la vista. No está diseñado/destinado a codificar toda nuestra lógica de aplicaciones. Si lo eres, definitivamente lo estás haciendo mal.

ASP clásico realmente no tenía una distinción fácil de lo que es ver el motor frente a lo que es el código.

0

Su pregunta implica que no está al día con ASP.NET MVC. Su pregunta se aplica a ASP.NET MVC WebForms, no solo a los archivos .cshtml o .vbhtml. Es decir, tu pregunta es sobre Vistas en MVC.

En términos de curvas de aprendizaje, está colocando el caballo antes del carro. Cualquier libro sobre MVC comenzará con una descripción de las diferencias entre MVC, ASP.NET plain vanilla, y lo que podría llamarse ASP.COM o ASP clásico.

La lógica que usted escribe en sus Vistas en MVC usando Razor o su motor de vista de elección es Mostrar Lógica. ASP clásico era cualquier lógica, negocio, pantalla, acceso a datos ...

Por lo tanto, para responder a su pregunta, debería preocuparse por MVC (en lugar de simplemente Razor) porque le permite dividir esa lógica en, uhmmm, contenedores lógicos . No lo mezclas todo en la Vista.

Es decir, lo que debe preocuparle, y decidir si le conviene, es ASP.NET MVC. Si decides que te importa MVC (porque te hace la vida más fácil y tus clientes más felices), ENTONCES definitivamente deberías preocuparte por Razor, porque te hace la vida aún más fácil.

+1

buenos consejos ... aunque en general creo que el caballo debería 'ir antes que el carro ;-) – puddleglum