Discussion :

[ptrs32]

Bonjour à tous,


Je contribue à la conception d'un projet Django de site web pour un laboratoire médical et j'aurais besoin de vos avis sur la meilleure organisation à adopter.

Pour le principe, ce laboratoire est divisé en plusieurs service et l'idée est de permettre à chaque futur utilisateur d'accéder à la partie du site web dédiée à son service.

Du coté des développeurs, chacun appartient à un service et travaillera donc uniquement au développement de la partie du projet dédiée à son service. En revanche, tout le projet partagera une même base de donnée.

Nous en sommes encore aux prémices et pour commencer sur des bases solides nous cherchons comment organiser l'architecture du projet afin que chacun s'y retrouve facilement et ne puisse pas malencontreusement modifier des scripts d'un collègue d'un autre service.

Nous ne sommes pas des pro de Django, alors instinctivement (et grossièrement) l'idée serait de grouper les différentes applications de chaque service dans des dossiers comme cela :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
 
mainProject
    - manage.py
    - mysql
    - mainProject      #contenant les codes et templates du menu principal commun à tous et les urls vers chaques services
        - settings.py
        - urls.py
        - views.py
        ...
    - service n°1   #contenant les codes, templates et liens spécifiques à ce service, comme un sous projet  
        - appli A
        - appli B
        - appli C
        ...
    - service n°2
        - appli D
        - appli E
        ...

Je me doute que ce schéma est très grossier mais c'est l'idée.

La questions est donc, pensez vous que ce système soit le bon ? Y a t-il des problèmes majeurs que vous voyez ? Avez vous d'autres idées d'organisation pour répondre au mieux à notre problème ?


N'hésitez pas à poser des questions si ce n'est pas clair.

Et merci d'avance !

[wiztricks]

Salut,

La questions est donc, pensez vous que ce système soit le bon ? Y a t-il des problèmes majeurs que vous voyez ? Avez vous d'autres idées d'organisation pour répondre au mieux à notre problème ?

C'est un choix d'organisation hiérarchique. Çà fonctionne bien pour séparer... mais vous avez intérêt à pouvoir mettre des choses en commun (un peu plus que la base de données) et ce genre d'horizontalité se gère assez mal avec une hiérarchie.

- W

[ptrs32]

mais vous avez intérêt à pouvoir mettre des choses en commun (un peu plus que la base de données).

Merci pour la réponse mais pourquoi cela ? Qu'est ce que ça va changer d'avoir des choses communes ou pas entre les services ?

ce genre d'horizontalité se gère assez mal avec une hiérarchie.

D'accord, et vous auriez une proposition d'organisation ?

[Arioch]

Bonjour,

nous avons pour habitude de gérer toutes les applications tournant autour de Django dans un dossier /apps avec à l'intérieur, un dossier (généré par python manage.py startapp) par application.

Si des classes/fonctions ont un usage touchant plusieurs applications, on les range dans /apps/core, ou encore /apps/common.

[Arioch]

Ce qui donnerait, en reprenant votre exemple de hiérarchie :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
mainProject
    - manage.py
    - mysql
    - mainProject      #contenant les codes et templates du menu principal commun à tous et les urls vers chaques services
        - settings.py
        - urls.py
        - views.py
        ...
    - apps
        - service n°1   #contenant les codes, templates et liens spécifiques à ce service, comme un sous projet  
            - appli A
            - appli B
            - appli C
            ...
        - service n°2
            - appli D
            - appli E
            ...
        - core # le code qui sera exploitable par plus d'une application

Si par exemple vous avez une classe Config() contenant vos variables d'environnement et autres paramètres de personnalisation, vous pouvez très bien la stocker dans /apps/core.

[wiztricks]

D'accord, et vous auriez une proposition d'organisation ?

A partir du moment où les développeurs sont "séparés" et dans leurs services, il y a d'abord une question d'organisation humaine.

Côté Python, ce pourrait être un package partageable entre A, B et C à réaliser avec ce que permet la machinerie d'import en fonction de règles de gestion (à définir).

Après vous réalisez peut être que montrer à quoi devrait ressembler le livrable "final" est peut être inadapté à la division entre services: ils vont tester leur prose indépendamment les uns des autres et on espère qu'ils respecteront le canevas proposé pour que l'intégration soit plus facile.

- W

[ptrs32]

Ce qui donnerait, en reprenant votre exemple de hiérarchie :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
mainProject
    - manage.py
    - mysql
    - mainProject      #contenant les codes et templates du menu principal commun à tous et les urls vers chaques services
        - settings.py
        - urls.py
        - views.py
        ...
    - apps
        - service n°1   #contenant les codes, templates et liens spécifiques à ce service, comme un sous projet  
            - appli A
            - appli B
            - appli C
            ...
        - service n°2
            - appli D
            - appli E
            ...
        - core # le code qui sera exploitable par plus d'une application

Si par exemple vous avez une classe Config() contenant vos variables d'environnement et autres paramètres de personnalisation, vous pouvez très bien la stocker dans /apps/core.

Merci beaucoup pour cet exemple, c'est toujours bon d'avoir un aperçu des différentes pratiques.*

A partir du moment où les développeurs sont "séparés" et dans leurs services, il y a d'abord une question d'organisation humaine.

Côté Python, ce pourrait être un package partageable entre A, B et C à réaliser avec ce que permet la machinerie d'import en fonction de règles de gestion (à définir).

Après vous réalisez peut être que montrer à quoi devrait ressembler le livrable "final" est peut être inadapté à la division entre services: ils vont tester leur prose indépendamment les uns des autres et on espère qu'ils respecteront le canevas proposé pour que l'intégration soit plus facile.

- W

Bien sûr, l'organisation sera proposée à tous et tout le monde devra se plier au choix final. Sinon ça serait impossible de travailler.
Merci beaucoup pour la proposition du package.

[Arioch]

Merci beaucoup pour cet exemple, c'est toujours bon d'avoir un aperçu des différentes pratiques.*

NB : la création des applications passe toujours par la commande :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

python manage.py startapp mon_appli

Et il faut juste "ranger" le dossier à la main dans /apps et rafraichir le path dans le settings.py du projet Django.

[ptrs32]

NB : la création des applications passe toujours par la commande :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

python manage.py startapp mon_appli

Et il faut juste "ranger" le dossier à la main dans /apps et rafraichir le path dans le settings.py du projet Django.

Oui, la création d'applications ne me pose à priori pas de problème mais c'est cette possibilité de les ranger autre part dont je n'était pas sûr. Merci !