Cuando tenemos mucho tiempo haciendo algo, es inevitable que hayamos creado una forma de hacerlo, por lo general nuestra propia forma de hacerlo. Si tuviste la oportunidad que te guiara alguien con experiencia, tú flujo de trabajo estará basado en la experiencia de alguien que ya haya caminado esa ruta y sepa por donde ir con más seguridad. Si no fue así y tuviste que conocer el camino por tu cuenta, es muy probable que te hayas caído en el camino, que hayas caminado en círculos, que te hayas extraviado, etc.
Una vez que has desarrollado una forma de hacer las cosas, lo más difícil es tener que cambiar, romper ese paradigma de cómo hacemos las cosas, es lo más difícil de aceptar. Es normal que nos resistamos al cambio, sin embargo, déjenme decirles algo: Cuando tu medio de trabajo es tan cambiante, es tan revolucionario, si cambia, cada poco tiempo, lo mejor que puedes hacer es mantenerte receptivo, abierto a esos cambios y tratar de aprender lo más rápido que puedas.
En lo personal, cada vez que empiezo a aprender una nueva tecnología, siempre trato de encontrar una guía, un forma segura, que no me haga perder el tiempo…de todas formas al estar aprendiendo cosas nuevas, estamos divirtiéndonos, no?
Bien, cual es el flujo de trabajo para MVC?
Las piezas del juego son: CONTROLLER, REPOSITORIO, INTERFACES, ENTIDADES, CLASES BUDDY.
Vertical u Horizontal
Cuando se construye una aplicación podemos ir creando y codificando cada capa antes de continuar con la siguiente. A esto le llamo construcción vertical. Si creamos las capas pero codificamos los métodos, sobre demanda o sea conforme lo vamos necesitando, estaríamos creando el flujo desde la capa más externa, hasta la más interna, a esto le llamo construcción Horizontal.
Este flujo de trabajo es Horizontal. A pesar de que hay más piezas en el juego, empecemos por estas.
1. Lo primero es decidir si usaremos el modelo a partir de las clases o a partir de la base de datos.
2. Si empezamos con el modelo de clases podemos usar el Entity Framework para diseñarlo y después creamos la base de datos a partir de el, con lo que ya tendríamos el código de las entidades y la persistencia.
3. Si primero creamos la base de datos, podemos crear el modelo de entidades a partir de la misma.
4. Una vez que se tiene el EF, podemos empezar por crear la interface para implementar el patrón de repositorio.
5. Implementamos el patrón de repositorio, sin que escribamos el código de sus métodos. Si es C#, este se creara con la THROW apropiado para poder continuar, si es VB, entonces deberán implementar este en cada método, para poder continuar.
6. Se debe crear un controller por cada entidad.
7. Partiendo de la idea que las acciones que trae por default son las del CRUD, debemos empezar por decidir cómo va a ser la vista que se requiere. A partir de esta vista podemos saber si va a ser suficiente con la entidad o si vamos a necesitar un ViewModel.
8. De ser necesario se crean los ViewModels.
9. Se crean los Views según se vaya codificando cada acción del controller.
Al menos estos pasos pueden servir como un inicio. Suerte.
No hay comentarios:
Publicar un comentario