¿Cómo organizar el código fuente de una aplicación hecha con SQLAlchemy y una interfaz gráfica?

Question

Estoy desarrollando una aplicación usando SQLAlchemy y wxPython que estoy tratando de mantener distribuida en módulos separados que consisten en lógica de negocios, ORM y GUI.

No estoy del todo seguro de cómo hacer esto de forma pitonica.

Dado que mapping() tiene que ser llamado orther para los objetos que se utilizarán, pensé en ponerlo en el __init__.py de la lógica bussiness, pero manteniendo todas las definiciones de tabla dentro de un módulo separado orm.py.

¿Debo mantener algo como:

/Business 
    /__init__.py 
    | mapping (module1.Class1, orm.table1) 
    | 
    /module1.py 
     Class1 

/orm.py 
    import 
    table1 = Table() 
/GUI 
    /main.py 
    | import business 
    /crud.py 

o algo así

/Business 
    /__init__.py 
    | import 
    | 
    /module1.py 
     Class1 
     table1 = Table() 
     mapping (module1.Class1, orm.table1) 

/GUI 
    /main.py 
    | import business 
    /crud.py 

se recomienda el primer enfoque? ¿Hay alguna otra opción? He visto la segunda manera, pero no me gusta poner el código de manejo de la base de datos y el código de la lógica de negocios dentro del mismo módulo. ¿Lo estoy pensando demasiado? ¿Realmente no es un gran problema?

Answer 1

Encuentro this document por Jp Calderone para ser un gran consejo sobre cómo (no) estructurar su proyecto de python. Siguiéndolo no tendrás problemas. Reproduzco el texto completo aquí:

estructura del sistema de archivos de un proyecto de Python

Haz:

• nombre del directorio algo relacionado con su proyecto. Por ejemplo, si su proyecto se llama "Twisted", nombre el directorio de nivel superior para sus archivos fuente Twisted. Cuando realice lanzamientos , debe incluir un sufijo de número de versión : Twisted-2.5.
• crear un directorio Twisted/bin y poner sus ejecutables allí, si tiene cualquiera. No les dé una extensión .py , incluso si son archivos fuente de Python . No coloque ningún código en excepto una importación de y llame a una función principal definida en otro lugar en sus proyectos.
• Si su proyecto es expresable como un solo archivo fuente de Python , luego ponerlo en el directorio y el nombre de algo relacionada con su proyecto. Por ejemplo, Twisted/twisted.py. Si necesita varios archivos fuente, crear un paquete lugar (Twisted/twisted/, con un vacío Twisted/twisted/__init__.py) y lugar los archivos de origen en el mismo. Para ejemplo, Twisted/twisted/internet.py.
• poner las pruebas unitarias en un sub-conjunto de su paquete (nota - esto significa que la opción de archivo fuente de Python sola anteriormente era un truco - siempre se necesita en menos otro archivo para su unidad pruebas) Por ejemplo, Twisted/twisted/test/. Por supuesto, lo convierten en un paquete con Twisted/twisted/test/__init__.py. Coloque las pruebas en archivos como Twisted/twisted/test/test_internet.py.
• agregue Twisted/README y T wisted/setup.py para explicar y instale su software, respectivamente, si se siente bien.

No:

• poner su origen en un directorio llamado src o lib. Esto hace que sea difícil de ejecutar sin instalar.
• pon tus pruebas fuera de tu paquete Python . Esto dificulta ejecutar las pruebas con una versión instalada.
• crea un paquete que solo tiene un __init__.py y luego coloca todo tu código en __init__.py. Simplemente haga un módulo en lugar de un paquete, es más simple.
• tratar de llegar a hacks mágicas para hacer Python capaz de importar su módulo o paquete sin tener que el usuario añada el directorio que lo contiene a su ruta de importación (ya sea a través de PYTHONPATH o algún otro mecanismo de ). No manejará correctamente todas las cajas y los usuarios recibirán molestos cuando el software no funcione en su entorno.