18 Oct Proyectos en Velneo: ¿Cómo estructurarlos?
Cuando comenzamos a desarrollar con la plataforma, una de las primeras cuestiones a resolver es la de cómo estructurar los proyectos en Velneo. Pues como diría un buen gallego: «depende».
En el post «¿Cuántos proyectos debe tener mi solución?» vimos que lo mas recomendable, es tener un solo proyecto de datos y un solo proyecto de aplicación.
En el post de hoy vamos a ver las ventajas y los inconvenientes de distintas formas de estructurar los proyectos en Velneo.
Tipos de estructura de proyectos en Velneo
Para saber la estructura que tienen que tener los proyectos, y por consiguiente nuestras soluciones, tendremos que responder a una serie de preguntas. Entre ellas podemos destacar las siguientes:
- ¿Mi aplicación va a ser heredada por otras soluciones?
- ¿Quiero facilitarle la vida a otros desarrolladores?
- ¿Cómo voy a distribuir mi solución? ¿Como un todo?, ¿Por módulos?
- ¿Quiero que mi solución sea la base de otras soluciones?
- ¿Quiero tener distintas instancias por módulo. o una instancia para todos los módulos?
En función de lo que contestemos, tendremos que estructurar nuestros proyectos.
Proyectos «Monolíticos»
Son aquellas soluciones que tienen un proyecto de datos y un proyecto de aplicación. Un ejemplo de esta estructura de proyectos en Velneo es mi aplicación GTDenlanube.
Estructura monolítica
Ideal cuando empezamos a desarrollar con Velneo V7. Evitamos complejidad.
Nos despreocupamos de crear tablas de extensión y herencia inversa.
Facilitan la herencia a otros desarrolladores.
No se puede trocear.
Dificulta el desarrollo colaborativo.
No es escalable al estar todos los módulos en el mismo proyecto.
Todo el peso está en la misma solución, con altos consumos de memoria a medida que añadimos funcionalidades. Si tuviesemos un ERP + CRM + TPV + CONTABILIDAD, tendríamos en una solo instancia todos los objetos... ahora imaginad mas módulos: cartera, producción, etc etc.
Proyectos «Verticales»
Son aquellas soluciones que tienen un proyecto de datos y varios de aplicación. Un ejemplo muy claro lo tenemos el vErp
Ya tenemos dos proyectos de aplicación perfectamente diferenciados: vTPV y vERP. Por lo tanto podemos instanciar por separado... aunque los datos siguen estando en la misma instancia.
Facilitan a los desarrolladores las personalizaciones sencillas
Los datos siguen estando en el mismo proyecto.
No es escalable
Proyectos «Horizontales»
Son aquellas soluciones que tienen varias soluciones independientes relacionadas por un proyecto que las hereda. Un ejemplo muy claro lo tenemos en los módulos de la plataforma PaaSOS de Tipesoft. Los módulos de PaaSOS tienen un único proyecto de datos y uno de aplicación…. heredando de un núcleo común (veremos este montaje «mixto» a continuación).
Módulos completamente independientes.
Perfectamente escalables.
Peso de las soluciones repartido evitando consumos de memoria desmedidos.
Facilita la extensión de nuestras soluciones.
Facilita el desarrollo colaborativo.
Complejidad en la visibilidad de los datos. Unos módulos no tienen "conocimiento" de los datos de su solución hermana.
Imposible la herencia entre soluciones "hermanas". Si es posible mediante la API de Velneo.
Si queremos utilizar varias soluciones, tendremos que "empaquetarlas" en distintos packs.
Proyectos «Mixtos»
Son aquellas soluciones, generalmente de tipo Monolítico que heredan otras soluciones (del tipo que sean). Son aquellas soluciones que creamos para no tocar o ampliar la solución base y poder beneficiarnos de futuras actualizaciones de dicha solución: soluciones que creamos heredando vERP, soluciones que creamos heredando el núcleo de PaaSOS
Facilitan la instalación de nuevas versiones de nuestra solución base.
Perfectamente escalables.
Facilitan la extensión de la solución.
Facilitan el desarrollo colaborativo.
Complejidad en la herencia de soluciones.
No están recomendados para usuarios que comienzan con la plataforma. Necesitan conocimiento de estructuras avanzadas en Velneo V7.
¿Ves alguna ventaja o inconveniente mas en la forma de estructurar nuestros proyectos en Velneo?
Coméntame tu experiencia mas abajo.
Gabri
Posted at 13:49h, 18 octubreHola Vila,
Buen artículo.
Me asalta una duda referente al consumo de memoria al que te refieres.
¿La memoria es consumida por las funcionalidades disponibles en los proyectos o por las N tablas a las que accede cada conexión.?
Es decir, sirva como ejemplo, si toda la lógica de negocio la tengo en un único proyecto ¿consume más que si separó por ejemplo la parte de núcleo de clientes?
Hasta ahora entendía que consumirá aquello de lo que haga uso, y en este ejemplo, entiendo que consumirá lo mismo cuando accedo a la cartera de clientes, independientemente si esta está en un único proyecto, o un proyecto separado.
Estaría bien un artículo al respecto, diferencias de estos planteamientos de desarrollo, pero enfocado al rendimiento.
Gracias por tus artículos
Saludos
Modelo de datos en Velneo. Primero resuelve el problema.
Posted at 11:42h, 25 octubre[…] ¿Será una solución de tipo mixto? […]