2008-09-24 10 views
8

Estoy confundido con la forma en que se organizan las vistas, y es importante entender esto ya que ASP.NET MVC usa las convenciones para que todo funcione correctamente.¿Cuál debería ser la estructura del archivo/directorio de vista en ASP.NET MVC?

En el directorio de vistas, hay subdirectorios. Dentro de estos subdirectorios hay vistas. Supongo que los subdirectorios se asignan a los controladores y los controladores actúan según las vistas que contienen sus subdirectorios.

¿Existe una expectativa emergente de qué tipos de vistas están contenidas dentro de estos directorios? Por ejemplo, ¿la página predeterminada para cada directorio debe ser index.aspx? ¿Deben las páginas seguir una convención de nomenclatura como Crear [controlador] .aspx, Lista [controlador] .aspx, etc.? ¿O no importa?

Respuesta

7

Ver nombres de directorios y nombres de archivos son importantes, porque el marco ASP.NET MVC tiene ciertas suposiciones sobre ellos. Si no se ajusta a estas suposiciones, debe escribir el código para que el marco sepa lo que está haciendo. En términos generales, debe ajustarse a estas suposiciones a menos que tenga una buena razón para no hacerlo. mirada

Vamos a la más simple acción del controlador posible:

public ActionResult NotAuthorized() 
    { 
     return View(); 
    } 

Debido a que ningún nombre de la vista se ha especificado en la llamada a Ver(), el marco supondrá que la vista nombre del archivo será el mismo que el de Acción nombre. El marco tiene un tipo llamado ViewEngine que proporcionará la extensión. El ViewEngine predeterminado es WebFormViewEngine, que tomará ese nombre y anexará un .aspx. Entonces, el nombre de archivo completo en este caso sería NotAuthorized.aspx.

¿Pero en qué carpeta se encontrará el archivo? Una vez más, ViewEngine proporciona esa información. Con WebFormViewEngine, que se verá en dos carpetas: ~/Views/Shared y ~/Vistas/{controlador}

lo tanto, si el controlador se llama AccountController, se vería en ~/Vistas/Cuenta

Pero hay Es posible que haya momentos en los que no quiera seguir estas reglas. Por ejemplo, dos acciones diferentes pueden devolver la misma vista (con un modelo diferente, o algo así). En este caso, si se especifica el nombre de la vista de manera explícita en su acción:

public ActionResult NotAuthorized() 
    { 
     return View("Foo"); 
    } 

Tenga en cuenta que con WebFormViewEngine, el "nombre de la vista" es generalmente el mismo que el nombre del archivo, menos la extensión, pero el marco no requiere el de otros motores de vista.

Del mismo modo, también podría tener una razón para querer que su aplicación busque vistas y carpetas no predeterminadas. Puede hacerlo creando su propio ViewEngine. Muestro la técnica en this blog post, pero los nombres de los tipos son diferentes, ya que se escribieron para una versión anterior del marco. La idea básica sigue siendo la misma, sin embargo.

+0

¿Pueden las carpetas dentro de la Vista tener subcarpetas? si es así, ¿cómo los alcanza el Controlador? Por ejemplo ... Admin/Profile/Edit/1 –

+0

Tendría que escribir su propio ViewEngine para hacer esto. WebFormViewEngine no los encontrará. –

+0

@Eric Configuración 'ViewLocationFormats' en la instancia del motor de vista de formulario web es todo lo que se necesita para habilitar la colocación de vistas en las subcarpetas. – bzlm

2

En cuanto a los nombres esperados para las vistas, creo que es una de esas cosas que cada proyecto u organización intentará estandarizar.

Como insinuó en su pregunta, es posible que algunas de estas Vistas (o más precisamente, las Acciones que las generan) se vuelvan populares en general, como las siguientes que son comunes en aplicaciones RoR que adoptan el paradigma REST:

  • /orders/(ieíndice)
  • /pedidos/mostrar/123
  • /órdenes/editar/123
  • /órdenes/actualización/123
  • /pedidos/nueva
  • /pedidos/crear
  • /pedidos/destruir/123

La elección/estandarización de las Vistas depende en gran medida de la forma en que modele su aplicación (para decir lo obvio) y de lo fino que desea ir. Cuanto más acerque a sus controladores a las clases de modelos individuales (tos ... recursos ... tos), más cortas serán sus acciones y más fácil será seguir un conjunto de acciones estándar (como en el ejemplo anterior))

También creo que las acciones más breves ayudan a empujar cada vez más de la lógica de negocio modelo a los propios modelos, donde corresponde.

Cuestiones relacionadas