Crear un paquete o modelo es una de las primeras cosas que haremos cuando empecemos a programar en un nuevo proyecto.
Es algo muy básico, pero sigo viendo algunos problemas sobre esto, malas prácticas que pueden convertirse en problemas en el futuro.
¿Paquetes o modelos?
¿Es un paquete algo distinto a un modelo? Bueno, más o menos, es algo más conceptual que otra cosa.
Un paquete es un grupo de uno o más modelos. Y los modelos son una sub estructura de los paquetes. Así que si tienes un paquete con un solo modelo, ese modelo también es un paquete. Lo importante aquí es que los paquetes se pueden… paquetizar y distribuir a otros entornos.
Para ser más claro: todo lo que hay en K:\AosService\PackagesLocalDirectory es un paquete. Por ejemplo ApplicationSuite es un paquete:
Y dentro de este paquete hay varios modelos:
Y una vez hecha esta pequeña explicación, vamos a lo importante.
¿Cómo deberíamos planear los paquetes y modelos?
Dejadme que empiece con esto, y dejad que lo escriba en mayúsculas, y en negrita, y en rojo: NO CREÉIS UN PAQUETE POR CADA DESARROLLO QUE HAGÁIS.
Tenemos que pensar en los paquetes como un contenedor de nuestro trabajo, y en los modelos como una forma de organizar objetos dentro de los paquetes. Así que podemos crear un paquete para nuestra organización, y dentro podemos crear todos los modelos que queramos, por ejemplo uno por módulo de Dynamics 365.
Y por supuesto podríamos poner todo dentro de un paquete con un único modelo. Estas deberían ser las dos formas de hacerlo.
Pero lo que no haremos, en ningún caso, nunca de la vida, es crear un paquete por desarrollo. ¡Y lo he visto! ¡Más de una vez! ¿Por qué no hacerlo? Porque es buscarse la ruina, y comprar un billete en primera clase directo al infierno. Vamos a ver algunas razones por las que no hacerlo.
Vas a odiar los pipelines de Azure
No es la más importante, pero es lo primero que siempre me viene a la cabeza. Imaginad que tenemos 20 paquetes para 20 desarrollos.
Cuando creamos la solución que se usa en nuestros pipelines de Azure, tenemos que crear una solución ¡con 20 proyectos dentro! Bueno, 20 no son tantos, pero ¿qué pasa si son 100?
Y ¿qué pasa con el mantenimiento de esta solución? ¡Vamos a estar actualizándola para cada desarrollo que hagamos! Y también tendremos que crear ramas con versiones de esta solución para poder ejecutar las pipelines de cada rama, hasta que vayamos moviendo los cambios a las ramas que vayan a prod o un entorno sandbox.
Referencias circulares
Esta es casi, casi la razón de más peso para no crear paquetes por desarrollo.
Imaginad que creamos un ModeloA, que contiene la tabla TablaA. Después creamos el ModeloB, con una referencia al ModeloA porque queremos usar la TablaA en una clase que se ejecutará por lote. ¡Sin problemas! ¡Hecho!
Después creamos un EDT en el ModeloB, y alguien quiere usarlo en el ModeloA. Ahora no podemos poner una referencia al ModeloB porque ya la hay en este hacia el ModeloA, y eso sería una referencia circular.
Con 2 modelos se arregla fácil, con 50 vas a querer cortarte las venas.
¡Me encantan las extensiones!
¡Claro que sí! Y si haces esto de un desarrollo, un paquete, acabaras con tropocientasmil extensiones del mismo form o tabla. Y cuando quieras modificar un control que creaste… ¡te vas a tirar medio día buscándolo entre tus queridas extensiones!
Tiempo de compilación
Esta no es muy importante, pero con tantísimos modelos, compilarlos todos en VS se eterniza.
Tu futuro tú te va a odiar
De verdad, esto es incluso más importante que las referencias circulares. Si troceas todos tus paquetes y modelos, y un día te das cuenta de lo que hiciste y lo quieres arreglar moviendo todo a un único paquete, va a haber mucho auto-odio.
