Código subyacente en ASP.NET MVC

Question

¿Cuál es el propósito del código detrás del archivo de vista en ASP.NET MVC además de la configuración del parámetro genérico de ViewPage?

Answer 1

Aquí está mi lista de razones por código subyacente puede ser útil tomada de my own post estoy seguro de que hay muchos más controles ASP.NET legado

• enlace de datos -.. si un la alternativa no está disponible o se necesita una solución temporal.
• Ver lo gic que requiere recursión para crear algún tipo de HTML anidado o jerárquico.
• Ver la lógica que usa variables temporales. ¡Me niego a definir las variables locales en mi sopa de etiquetas! Me gustaría tenerlos como propiedades en la clase de vista como mínimo.
• Lógica que es específica solo para una vista o modelo y no pertenece a un HtmlHelper. Como nota al margen, no creo que un HtmlHelper deba saber sobre ninguna clase 'Modelo'. Está bien si conoce las clases definidas dentro de un modelo (como IEnumerable, pero no creo, por ejemplo, que deba tener un HtmlHelper que tome un ProductModel. Los métodos HtmlHelper terminan siendo visibles desde TODAS sus vistas cuando escribe Html + dot y realmente quiero minimizar esta lista tanto como sea posible.
• ¿Qué pasa si quiero escribir código que utiliza HtmlGenericControl y otras clases en ese espacio de nombres para generar mi HTML de una manera orientada a objetos (o tengo código existente que lo hace que quiero exportar)
• Qué sucede si planeo usar un motor de visualización diferente en el futuro. Es posible que desee mantener algo de lógica aparte de la sopa de etiquetas para que sea más fácil reutilizarla más tarde.
• ¿Qué pasa si quiero ser capaz de cambie el nombre de mis clases de modelo y haga que refactorice automáticamente mi vista sin tener que ir a view.aspx y cambiar el nombre de la clase.
• ¿Qué pasa si estoy coordinando con un diseñador de HTML en quien no confío para no estropear la 'sopa de etiquetas' y quiero escribir algo más allá del bucle básico en el archivo .aspx.cs.
• Si desea ordenar los datos en función de la opción de ordenación predeterminada de la vista. Realmente no creo que el controlador deba clasificar los datos por usted si tiene múltiples opciones de clasificación accesibles solo desde la vista.
• En realidad, quiere depurar la lógica de vista en el código que reallky ​​parece .cs y no HTML.
• Desea escribir el código que se puede factorizar más adelante y reutilizar en otro lugar; aún no está seguro.
• Desea crear un prototipo de lo que puede convertirse en un nuevo HtmlHelper pero aún no ha decidido si es lo suficientemente genérico o no para garantizar la creación de un HtmlHelper. (básicamente igual que el punto anterior)
• Desea crear un método de ayuda para representar una vista parcial, pero necesita crear un modelo para ello sacando datos de la vista de la página principal y creando un modelo para el control parcial que es basado en la iteración del bucle actual.
• Cree que la programación de la lógica compleja IN A SINGLE FUNCTION es una práctica desactualizada e inmanejable.
• ¡Lo hiciste antes de RC1 y no tuvo ningún problema!

Sí!Algunas vistas no deberían necesitar codebehind en absoluto.

Sí! Es una mierda obtener un estúpido archivo .designer creado además del archivo .cs.

Sí! Es un poco molesto tener esos pequeños signos al lado de cada vista.

PERO - Realmente no es tan difícil NO poner la lógica de acceso a datos en el código subyacente.

Ciertamente NO son evil.

Answer 2

No hay un propósito. Eso sí, no utilizarlo salvo para ajustar el modelo

ViewPage<Model> 

Ver this entrada de blog para obtener más información.

Answer 3

Esta es una gran pregunta. No existe MVC en el entorno ASP.NET, sin utilizar el patrón MVC específico.

Ver = aspx

Controlador = aspx.cs (código subyacente)

(Plain Old objetos de C#/VB/.NET) Modelo = POCO

me pregunto por qué la funcionalidad añadida de El marco MVC es útil. Trabajé significativamente con Java nd MVC y Java Struts hace varios años (2001), y encontré los conceptos en MVC como una solución para la organización de aplicaciones de Internet y los problemas de desarrollo en ese momento, pero luego descubrí que el código simplificaba el concepto de controlador y era más rápido para desarrollar y comunicarse con los demás. Estoy seguro de que otros no están de acuerdo conmigo y estoy abierto a otras ideas. El mayor valor que veo para MVC es el patrón de controlador frontal para desarrollo de Internet, fuente de entrada única para la aplicación de Internet. Pero, por otro lado, ese patrón es bastante simple de implementar con las tecnologías ASP.NET actuales. He escuchado a otros decir que el Análisis de Unidad es el razonamiento. Puedo entender eso también, usamos JUnit con nuestro framework MVC en 2001; pero no he estado convencido de que simplifique las pruebas para usar el marco te MVC.

¡Gracias por leer!

Answer 4

En this Blogpost es un ejemplo de trabajo para eliminar el código. El único problema que tengo es que no puede establecer espacios de nombres en la clase.

Answer 5

El código subyacente proporciona algunos de los tipos de tipeo robustos así como el soporte intellisense que obtienes en la vista. Si no le importa ninguna de estas dos funciones, puede eliminarla.

Por ejemplo, normalmente utilizo NVelocity ViewEngine porque es limpio y bastante directo.

Answer 6

En última instancia, la cuestión que se pregunta es la siguiente:

Hace este código A) Proceso, almacenar, recuperar, o realizar operaciones en analizar los datos, o B) Ayuda para visualizar los datos?

Si la respuesta es A, pertenece a su controlador. Si la respuesta es B, entonces pertenece a la vista.

Si B, finalmente se convierte en una cuestión de estilo. Si tiene algunas operaciones condicionales bastante largas para tratar de averiguar si visualiza algo para el usuario, entonces puede ocultar esas operaciones condicionales en el código de una Propiedad. De lo contrario, parece que la mayoría de las personas colocan el código en línea en la interfaz utilizando las etiquetas <%%> y <% =%>.

Originalmente, pongo todos mi lógica de visualización dentro de las etiquetas <%%>. Pero recientemente me he tomado la molestia de poner algo desordenado (como un condicional largo) en mi código para mantener mi XHML limpio.El truco aquí es la disciplina: es demasiado tentador comenzar a escribir lógica comercial en el código subyacente, que es exactamente lo que debería hacer en MVC.

Si está tratando de pasar de ASP.NET tradicional a ASP.NET MVC, puede observar el código subyacente hasta que tenga una idea de las prácticas (aunque todavía no le impide poner la lógica empresarial dentro . la <%%>