Por que dividir una solución en varios proyectos?


([N3] ereitmann) #1

Hola… hago una pregunta desde mi ignorancia y es cual es el beneficio de dividir una solución en varios proyectos?..y cuales los inconvenientes de no hacerlo?.. yo hasta ahora he realizado soluciones no muy complejas y alguna de mediana complejidad (para mi al menos) y siempre las dividí en 2 proyectos (datos y aplicación). por otra parte cuando he querido instalar soluciones como vbase, para hacer pruebas me he encontrado con un lío de instancias que siempre hay que dar de alta en el vadmin de forma manual y considero algo engorroso para un usuario final… también pienso e que puede resultar un poco complicado el mantenimiento de tantos proyectos en el servidor cuando se hace alguna actualización… por favor los que saben… que recomiendan al respecto ??


([N3] blavan) #2

Hola, no te contesto porque no tengo base para ello,pero estoy deseando ver respuestas en ese sentido.
Yo hago lo mismo que tú, cuando tengo que heradar pues heredo pero dentro de la misma solución me encuentro más cómodo con proyecto y proyecto de datos.
Puede ser que pensando en un futuro al tener la solución más dividida otra nueva solución sólo tenga que heradar de un proyecto no de toda la solución por ahí debe de ir los tiros


([N2] AyudaVelneo) #3

Hola:

Dependerá mucho de que vayas a hacer con tu aplicación:

<li><strong>Si es de uso interno</strong>, no te compliques la vida: un proyecto de datos y otro de aplicación.</li>
<li><strong>Si vas a vender toda tu aplicación y vas a ir quitando o añadiendo módulos</strong>, una única solución con varios proyectos (sobre todo de aplicación) y podrías dejar un solo proyecto de datos... mas o menos es como está estructurado vErp</li>
<li><strong>Si vas a montar una tienda para que los usuarios compren módulos de tu aplicación</strong>: una solución común y luego soluciones independientes por cada uno de los módulos a vender.. es como está estructura PaaSOS de tipesoft</li>

También te puede servir para tener estructurada tu aplicación sobre todo a la hora de desarrollar en equipo. Ten en cuenta que si un desarrollador tiene abierto un proyecto, otro desarrollador no podrá trabajar en él por lo que si sólo tienes un proyecto de datos y uno de aplicación… mal lo llevamos.

Un saludo


([N1] wikan) #4

Es según tus necesidades.
Por comodidad 1:1 y listo, si vas a tener un producto completamente cerrado. Te será mas cómodo.

Pero…
Piensa en “funcionalidad-módulos”, si los haces en proyectos separados, incluso en soluciones. Podrás heraderlo desde otro proyecto que requiera dicha función.

Por ejemplo, vBase y los usuarios. Puedes heredar solo los usuarios y ya te llevas tablas y formularios.

Pero es muy cierto lo que dices, entre más proyectos…el vAdmin es…para eliminar una instancia de datos te vuelves loco. Debe permitir borrar un árbol.


([N4] velavisual) #5

Mi opinión es que si hubiese un gestor de instancias que gestionase todas las posibilidades, este tipo de preguntas posiblemente no se harían.

Ejemplo:

  • Solución con múltiples proyectos y que se pudiese generar una solución final con un solo proyecto de aplicación y otro de datos.Fácil a la hora de instanciar.

  • Solución con múltiples proyectos y que se pudiese generar una solución final con determinados proyectos de aplicación y de datos especificando los que deben ser independientes. Cuestión de instancias.

Creo que este tipo de gestor de instancias podría tener muchos colores.


([N3] ereitmann) #6

Gracias por las respuestas, confirman un poco lo que pensaba al respecto… buena la idea de Velavisual sobre el gestor de instancias, deberían ser opciónes en el Vintallbuilder de velneo


([N1] carlaarana) #7

Hola chicos

Soy nueva en esto de velneo y tambien habia observado esta “circunstancia” sugiero para esto que la instruccion “Interface:Ejecutar accion” tenga un atributo de recibir el nombre de la “accion” en un campo “formula dato”.

Esto, desde mi experiencia en miles de pequeños modulos individuales segun tareas especificas para muchos tipos de usuarios, en otras (ejemplo vfp) se permitia definir una tabla de aplicaciones algo asi:

tabla
usuario, cod_app, definicion_nombre_app, nombre.app

entonces… en una sencilla pantalla solo habia un campo para ingresar el cod_app (codigo de aplicacion de diferentes funciones administrativas) segun el usuario.

Chicos brillantes EQUIPO VELNEO atento a mi observacion.

saludos chicos del foro


([N3] pacosatu) #8

Hola ereitmann.

Tu pregunta ha sido ¿Por que dividir una solución en varios proyectos? ¿Ventajas e incovenientes de hacerlo?

Según mi punto de vista.

Ventajas —>
Pues es lo que siempre se ha hecho en cualquier proyecto de Aplicación, modularizar para facilitar la gestión y mantenimiento a largo plazo del proyecto.
Por un lado tienes que modularizar los recursos multimedia (gráficos corporativos, iconos, fondos, estilos, constantes, …) y los componentes externos multiplataforma (DLL’S, Javascript, DHTML, XML, JSON, …).
Por otro lado tienes que modularizar los componentes funcionales de tu proyecto (Gestión de Usuarios, Preferencias, Módulo1, Módulo2, …).

No te olvides que es la mejor manera de tener control de Versiones, de intercambiar módulos, de facilitar actualizaciones parciales y … la única manera de usar la herencia de Velneo.

Velneo cachea los proyectos (ficheros VCA, VCD) en el equipos cliente. Imagina si tuvieras 20Mb de recursos gráficos en el mismo proyecto VCA cuyo código fuente estás modificando cada día. Cada vez que actualizas el proyecto VCA obligarías a vClient a cachear innecesariemente los 20Mb de recursos gráficos.

Desventajas —>
Ninguna a priori. A posteriori la única desventaja que le veo es la complejidad absurda que ha introducido Velneo en la gestión de las instancias con vAdmin.

La solución es la idea propuesta por Antonio Vela, separar el concepto de Proyecto o módulo de mi Aplicación del de Instancia de Velneo.

Conclusión: modulariza tus aplicaciones como siempre has hecho que la gestión de instancias, de tan precaria que es, tarde o temprano mejorará.

Saludos
Paco Satué


([N3] ereitmann) #9

Gracias Paco, comprendo las utilidades… y confirmo que a todo el mundo le resulta molesto la forma de instanciar los proyectos, pero por otra parte si creamos soluciones que sean escaladas, o con distintos niveles de funcionalidad según el pago del cliente, que otra forma abría de instanciar esos módulos funcionales?