Sigo escuchando sobre el Principio DRY y cómo es tan importante en ASP.NET MVC, pero cuando investigo en Google, no parece entender exactamente cómo se aplica a MVC.¿Cómo se ve realmente el principio DRY en ASP.NET MVC?
Por lo que he leído no es realmente la copia & pegar código de olor, lo que pensé que era, pero es más que eso.
¿Alguno de ustedes puede darnos una idea de cómo podría usar el principio DRY en mi aplicación ASP.NET MVC?
FormsAuthentication.Logout()(7 años después ...) ¿Qué se entiende por mantener las acciones del controlador "tontas"? –
Absolutamente, significa pocas líneas de código en un método de acción. En cuanto al diseño, significa que las acciones del controlador deberían ser responsables de gestionar el flujo del guión gráfico de la aplicación (post-redirect-get, por ejemplo), y dejar el procesamiento del modelo de entrada o construir el modelo de vista para otra cosa. –
Gracias Matt, lo entiendo ahora –
DRY simplemente significa "No repetir". Asegúrese de que cuando escribe código, solo lo escriba una vez. Si se encuentra escribiendo funcionalidades similares en todas sus clases de Controlador, cree una clase de controlador base que tenga la funcionalidad y luego herede de ella, o mueva la funcionalidad a otra clase y llámela desde allí en lugar de repetirla en todos los controladores.
DRY no es específico de ninguna tecnología one. Solo asegúrate de mirar tus clases desde el punto de vista de la funcionalidad (ni siquiera desde la vista del codificador copiar/pegar) y ver dónde ocurre la duplicación. Este proceso probablemente no ocurra de una sola vez, y solo notará la duplicación después de revisar su código varios meses después al agregar una nueva función. Si tiene pruebas unitarias, no debe temer eliminar esa duplicación.
No repita el proceso. Se puede aplicar a muchos aspectos diferentes de la programación. El nivel más básico de esto es evitar el olor del código. No he usado ASP.NET, así que no puedo ser específico para él y MVC.
Cuando repasa un "pensamiento" en un proyecto. Pregúntese.
Una de las ventajas de MVC en lo que respecta a no repetirse es que su controlador puede realizar tareas comunes a todas las páginas en una clase. Por ejemplo, la validación en contra de ciertos tipos de solicitudes maliciosas o validación de autenticación puede ser centralizada.
DRY no solo se debe aplicar al código, sino a la información en general. ¿Estás repitiendo cosas en tu sistema de compilación? ¿Tiene datos que se deben mover a un archivo de configuración común, etc.
Bueno, el ejemplo más común que puedo dar sobre DRY y UI es utilizar cosas como MasterPages y UserControls.
Las páginas maestras se aseguran de haber escrito todo el HTML estático solo una vez.
UserControls garantizan la reutilización del código. Por ejemplo, tendrás muchas formas haciendo cosas básicas como CRUD. Ahora, idealmente queremos que todos los usuarios vean diferentes páginas para Crear y Actualizar aunque los campos de formularios en ambos serán casi iguales. Lo que podemos hacer es combinar todos los controles comunes y ponerlos en un control que pueda reutilizarse en ambas páginas. Esto garantiza que nunca volvamos a escribir (o copiar y pegar) el mismo código.
DRY es especialmente importante en MVC debido al aumento en la cantidad de archivos para realizar la misma tarea.
Parece haber una idea errónea de que todo en un modelo de dominio debe copiarse como un modelo de vista especial. Puede hacer que los modelos de dominio sean modelos de dominio, pero los modelos de vista sean algo que no sepa nada de los detalles del dominio y sea más genérico. Por ejemplo: Las clases del modelo
de dominio: Cuenta, activos, PurchaseOrder
Ver Modelo: Lista, Tabla, tupla, SearchFormBackingModel: opciones marcadas, Outputoptions, etc. La vista en sí podría ser mucho más implantación vista específica.
El Tuple/Dictonary/Map puede asignarse a instancias individuales de Cuenta, Activo y Compra, pero una Tabla puede ser útil para una colección de ellas, etc. Todavía tiene MVC pero tiene datos de sesión, todavía no listos para la transacción en un ver el modelo sin que necesariamente viole las reglas de su modelo de dominio, que es donde deberían ir las reglas. Serán menos anémicos y antipatrón de esa manera. Puede pasar estas reglas por adelantado y usarlas allí o solo en la parte posterior o ambas, dependiendo de cómo el sistema lea de los clientes, etc.
Simplemente no se repita. :) (Lo siento, no pude resistir) – Craig