una - En Delphi, ¿debería agregar unidades compartidas a mis proyectos, a un paquete compartido, o ninguno?
google drive (5)
Necesitaría una muy buena razón para agregar código compartido a un paquete. Si solo tiene unos pocos archivos compartidos, péguelos en un directorio llamado Compartido. Esto debería hacer obvio que los archivos se comparten entre proyectos.
También use una buena herramienta de compilación para construir automáticamente, de modo que pronto descubrirá si rompe algo.
Los archivos .bpl están bien para los componentes, pero aportan una gran complejidad adicional para cosas como esta, a menos que tenga una gran cantidad de archivos compartidos.
Esta pregunta es similar a esta , pero no es un duplicado porque estoy preguntando sobre temas no discutidos en esa pregunta.
Tengo un proyecto de cliente-servidor en Delphi 7 con la siguiente estructura de directorio:
/MyApp
/MyClientApp
/MyServerApp
/lib
Hay 2 proyectos reales de Delphi (.dpr), uno en las carpetas MyClientApp y MyServerApp.
La carpeta lib tiene unidades .pas que tienen código común para las aplicaciones de cliente y servidor. Lo que me pregunto es si debería incluir esos archivos .pas en los proyectos de cliente y servidor. ¿O debería crear un paquete en la carpeta lib que incluye esas unidades? ¿O debería dejar los archivos .pas en la carpeta lib y no agregarlos a ninguna aplicación / paquete?
¿Cuáles son los pros / contras de cada enfoque? ¿Qué camino es el "mejor"? ¿Hay algún problema al incluir esas unidades de la carpeta lib en más de un proyecto?
En este momento, las unidades en la carpeta lib no son parte de ninguna aplicación / paquete. Una desventaja de esto es que cuando tengo mi aplicación cliente abierta en Delphi, por ejemplo, y quiero buscar algo en todos los archivos del proyecto, tampoco busca en las unidades de la carpeta lib. Lo soluciono abriendo esas unidades y haciendo un descubrimiento en todos los archivos abiertos, o usando la búsqueda grep (pero preferiría una mejor solución).
También preferiría en gran medida una solución en la que no tenga que abrir un paquete separado y volver a compilarlo cuando realice cambios en esos archivos en la carpeta lib (¿es aquí donde debería usar un grupo de proyectos?).
No me gusta tener archivos compartidos por proyectos. Con demasiada frecuencia, tendrá la tentación de editar uno de los archivos compartidos, y romperá algo en el otro proyecto, o se olvidará de que debe reconstruir el otro proyecto.
Cuando los archivos compartidos están separados en su propia biblioteca (paquete), existe una pequeña barrera adicional para editarlos. Considero que es algo bueno. Será un recordatorio ligero de que está cambiando de código específico del proyecto a código compartido. Puede usar grupos de proyectos para permitirle mantener todos juntos en una sola instancia de IDE. organizar los proyectos de la biblioteca antes de los proyectos ejecutables. El comando "construir todo" construirá todo en orden, comenzando con el primer proyecto.
Mantenga sus archivos DCU separados de sus archivos PAS. Puede hacerlo fácilmente configurando la opción del proyecto "DCU output directory" para enviar las unidades de su paquete a otra ubicación. Luego ponga ese directorio de destino en la "ruta de búsqueda" de sus otros proyectos. Encontrarán la DCU, pero no encontrarán el archivo PAS, por lo que ningún otro proyecto recompilará accidentalmente una unidad que realmente no sea miembro.
Tener un paquete separado también desalienta el uso de definiciones condicionales específicas del proyecto. Esos causan todo tipo de problemas cuando compartes unidades entre proyectos. Encuentre una manera de mantener todas las opciones específicas del proyecto dentro de los proyectos respectivos. Una biblioteca compartida no debería requerir modificaciones específicas del proyecto. Si una biblioteca necesita actuar de forma diferente en función de quién la está usando, entonces emplee técnicas como las funciones de devolución de llamada que el usuario de la biblioteca puede configurar para modificar el comportamiento de la biblioteca.
Normalmente creo un paquete con todas las unidades compartidas, y solo uso las unidades. Si no marca explícitamente "Generar con paquetes de tiempo de ejecución", el contenido del paquete (todos los archivos dcu usados) se vinculará a su proyecto como cualquier otra unidad.
Solo usaría paquetes de tiempo de ejecución si tuviera dos binarios que se suponía que se ejecutaran en la misma máquina física y que compartieran algún código. Tenga en cuenta que los paquetes de tiempo de ejecución son principalmente un enfoque de todo o nada. Una vez que decida usarlos, ya no podrá vincular las unidades RTL y VCL directamente a sus proyectos y, en su lugar, tendrá que implementarlas por separado.
Sin embargo, los paquetes pueden ser una buena solución a su problema cuando se combinan con grupos de proyectos, que es exactamente lo que estoy haciendo. Odio tener unidades compartidas incluidas en proyectos múltiples. Incluir las unidades compartidas en un paquete (pero no compilar sus proyectos reales con paquetes de tiempo de ejecución) le permite agregar ese paquete a su grupo de proyectos para que usted (y el IDE!) Siempre los tengan fácilmente accesibles pero separados del proyecto específico código. Estrictamente hablando, ni siquiera tiene que compilar esos paquetes. Simplemente pueden servir como una unidad organizativa en el administrador del proyecto.
Tenga en cuenta que para Buscar en archivos, también puede especificar "en todos los archivos en el grupo de proyectos"
Compartir unidades entre aplicaciones siempre conlleva el riesgo de que se realicen cambios incompatibles en una aplicación que rompa la otra. Por otro lado, hacer copias de estas unidades es aún peor, por lo que su propuesta de moverlas a su propio subdirectorio al menos agrega una barrera psicológica para cambiarlas sin considerar otros programas.
En cuanto a agregarlos a los archivos del proyecto: generalmente agrego algunas unidades a las que accedo con frecuencia (ya sea para expandir o para referencia) desde el IDE al proyecto, y dejo otras para que el compilador elija usando la ruta de búsqueda. Lo hago por proyecto, es decir, algunas unidades pueden ser parte de varios proyectos, ¿por qué no?
Ponerlos en un paquete solo tiene sentido, si realmente quieres crear una aplicación basada en paquetes, de lo contrario, ¿para qué molestarse?
Para obtener más información sobre cómo organizo mis proyectos y bibliotecas, consulte http://www.dummzeuch.de/delphi/subversion/english.html