Buenas prácticas del patrón MVC.

Desde Que empecé a escribir código para MVC pude notar la enorme preocupación de quienes lo crearon, en el sentido de ofrecer mecanismos para hacer las cosas bien, con seguridad, para tener el control desde el principio.

Al conjunto de lineamientos para hacer las cosas bien, suele denominársele BUENAS PRACTICAS, no son reglas, no son verificadas por el compilador, ni afectan que la aplicación se ejecute; sin embargo si no las ponemos en práctica, es muy probable que nuestra aplicación se encuentre en riesgo o resulte extremadamente complicado su mantenimiento y escalabilidad…

 

Introducción.

Este articulo contiene algunos lineamientos basados en mi propia experiencia desarrollando código MVC, mismos que fueron asimilados de diversas fuentes y que he ido incluyendo en la metodología y la arquitectura que empleo para crear aplicaciones con MVC.

 

Generales.

1. Lo primero es recordar en todo momento es el principio KISS.
2. Cuando sientas que se esta complicando, detente y revisa si hay alguna forma mas sencilla de hacerlo.
3. Antes de dedicarle tiempo a desarrolla algo investiga si no existe algo que puedas utilizar en NuGet.
4. Recuerda que si vas a emplear una biblioteca gratuita, no debes actualizarla sin tomar precauciones.
5. Crea un proyecto de prueba para cada biblioteca antes de usarla, donde evalúes su funcionalidad.
6. Asegúrate de comprender a fondo cada uno de los puntos que puedes personalizar antes de intentarlo.
7. Evita las “Cadenas Mágicas” que puedes crear con mecanismos como ViewData, no son seguras.
8. Los convenios que recomienda Microsoft, deben ser un punto de partida, aun que siempre resultara más seguro crear y usar los propios.
9. Trata de comprender a fondo cada patrón que se mencione en relación con MVC.
10. Asegúrate de respetar el patrón PRG o Post, Re direct y Get, en relación a tus Acciones.
11. Refuerza la estructura de capas.
12. Asígnale a cada capa una responsabilidad directa y asegúrate que una capa no pueda “brincarse” a otra para llegar a una capa que se encuentra después de la inmediata.
13. Recuerda aplicar el principio SoC, crea clases especializadas con responsabilidades bien definidas..
14. No tengas miedo de escribir código HTML (ni JavaScript, ni CSS).

Validación.

1. Reforzar la validación usando DataAnnotations en el ViewModel.
2. Sin embargo La validación que nos ofrece MVC es básica, es mejor usar alguna biblioteca como FluentValidation, para reforszar SoC.
3. Asegúrate de crear reglas de validación específicas para cada elemento en un ViewModel.
4. Las entidades del dominio, son diferentes a los ViewModels.
5. Emplea VM para las vistas y jamás expongas las Entidades.
6. El mecanismo de DataBinding puede ser un punto débil por medio del cual tu aplicación resultara vulnerable; cuida los datos que expones en una vista, valídalos siempre antes de moverlos a una entidad.
7. Asegúrate de atrapar todos los errores que genera la aplicación, en cualquier nivel.

Seguridad.

1. La seguridad se debe considerar desde el diseño.
2. El proyecto debe iniciar con el mecanismo de seguridad.
3. Todo acceso debe estar prohibido y se abrirán conforme se vaya programando, para garantizar que se respeten las políticas establecidas al respecto.
4. Si van a crear entidades para sus usuarios, como podrían ser proveedores, clientes, empleados; asegúrense de tener una entidad específica e independiente para controlar la seguridad.
5. Siempre es mejor establecer permisos en perfiles que en usuarios específicos.
6. Si vas a usar el AccountController, asegúrate de personalizarlo.
7. Evita usar el código “demo” que se crea con la plantilla.

Controller.

1. Asegúrate de mantener las acciones en el controller lo mas “delgadas” posible, esto quiere decir que las acciones deben responder al CRUD.
2. El controller únicamente sirve como un ruteador que se asegura que la ejecución del código sea en el orden apropiado.
3. El controller recibe las solicitudes.
4. El controller valida los datos.
5. Obtiene la información que se debe Regresar.
6. Se la envía al motor de vistas.
7. El controller también es responsable de re direccionar solicitudes.
8. Evita escribir código en el Controller que acceda a datos.

Views.

1. Las vistas deben ser “Tontas” evita escribir lógica de negocios o de validación.
2. Conserva las vistas limpias de código que no sea HTML.
3. Evita incluir código JavaScript en la vista.
4. Usa JQuery cada vez que puedas.
5. Si debes usar Código diferente al HTML, trata de simplificarlo, hasta reducirlo a validaciones sencillas de valores bool o escribe un HtmlHelper para encapsular esa lógica.
6. Jamás accedas a la capa de datos desde una vista.
7. Si una vista se complica, recurre a vistas parciales.
8. Si detectas que una parte de la vista se repite, conviértela en vista parcial.
9. Si detectas que una vista puede ser reutilizada en otros Controllers, conviértela en una vista compartida.
10. Crea un ViewModel por cada Vista.
11. El Model de una vista siempre será a partir de un VM.
12. Si necesitas un dato extra para la vista añádelo al Viewmodel.
13. Conserva los estilos independientes de la vista.

Model.

1. Asegúrense de usar ViewModels fuertemente tipificados.
2. Las entidades corresponden a un registro de una tabla especifica.
3. Dentro de esta podemos agrupar clases para reforzar nuestra arquitectura de capas.
4. Crea clases especializadas, con responsabilidades y alcances limitados.
5. La capa de Servicios recibe VM y regresa VM.
6. La capa de servicios es la única que se comunica con la capa de datos.
7. La capa de servicios se encarga de realizar la “traducción” de VM en entidades y viceversa.
8. Se recomienda usar Automapper para la traducción de datos entre VM y entidades.
9. La capa de servicios se encarga de las transacciones.
10. La capa de datos está formada por clases especializadas que implementan el acceso a los datos.
11. Se recomienda usar el Patrón de Repositorio para esta capa de datos.
12. La capa de datos trabaja únicamente con Entidades.

Comentario Final.

Quiero dejar en claro que no es mi intensión presionarlos para usar mi estructura o mis reglas de programación, sin embargo me atrevo a compartirlas porque considero que han llegado un punto de madurez que vale la pena tomarlas en cuenta.

Léanlas, analícenlas, si les sirven adóptenlas, si creen que pueden mejorarlas háganlo; simplemente tomen estos lineamientos como un punto de partida. Espero que les sea de utilidad.

Suerte.