Soit on pars d'un truc minimaliste et on construit dessus. Ça permet de rendre explicite tout ce qui se passe [...].
Ce qui rend le code compréhensible par tout développeur connaissant le langage mais pas forcément les bibliothèques utilisées.
Mais il peut être plus compliqué de rentrer dans le code car, justement, il a ses propres conventions. Ça peut aussi être plus compliqué, il peut y avoir des bugs subtils car l'intégration de la façon de gérer la base de données et les contrôleurs web ne correspond pas vraiment. La maintenance dans le temps peu aussi être plus complexe : mettre à jour une bibliothèque peu casser toute son intégration.
La maintenance d'une appli django est très compliquée. Les fonctionnalités de Django évoluent vite, et comme c'est basé sur des conventions qui changent/s'enrichissent, c'est très difficile de savoir ce qui est disponible et ce qui ne l'est pas sur une application donnée. Par ailleurs, les conventions et la "magie" de Django rendent des sujets a priori simples très compliqués à comprendre pour quelqu'un qui ne connait pas ou peu le framework.
Je vais prendre juste un exemple : Django propose un mécanisme de signaux pour exécuter des "triggers". C'est chouette ça simplifie l'écriture du code et tu arrives rapidement à l'objectif. Mais à lire/relire/maintenir/faire évoluer c'est une autre histoire.
Django est très bien si tu fais du pur développement web (par exemple : l'idée de réutiliser des briques de code ailleurs que dans un contexte web, c'est pas vraiment fait pour... et l'archi de Django ne t'incite pas à découper ton code en vue/logique/modèle ). Si tu es dans un environnement partiellement hors web, j'aurais tendance à ne pas partir sur un Django.
L'avantage de Django, c'est que si tu fais des choses web "classiques", tu vas hyper vite car tout est fait pour (modules disponibles, comportements par défaut correspondant à 90% des cas d'utilisation). A un moment leur tagline était qqchose comme "Django, the web application framework for projects with deadlines". En gros pour écrire vite (et si possible bien). Et ça marche bien dans ce contexte. Par exemple la gestion des migrations de modèles de base de données, les interfaces d'admin... c'est du clé-en-main. Et tu as une communauté qui créé des modules ou applications pour django qui te permettent de construire en assemblant des briques.
Mais si tu veux sortir des sentiers battus (ou prévoit de le faire), avec Django tu vas tordre ta logique de développeur pour la faire rentrer dans le moule Django et non l'inverse. Et ça, c'est pas forcément une bonne idée.
La customisation de certains élément peut, par contre être plus complexe (elle demande généralement à bien comprendre le framework).
La moindre sortie de la route tracée par Django rend le code extrêmement plus complexe.
C'est ce qui va distinguer les microframeworks comme Flask ou Sinatra des gros framework comme Django ou Rails.
Pour compléter (ou reformuler) : un framework comme Flask va te laisser choisir les briques que tu assembles, en te proposant des solutions standards (par exemple : associer SQLAlchemy avec Flask) mais pas obligatoires. Ces solutions sont de la documentation que tu vas décider de suivre ou pas. Dans un framework comme Django ça sera inclut d'office, voire difficile à remplacer si tu veux utiliser autre chose.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Position par rapport à Django ?
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse à la dépêche Sortie de Flask 1.0. Évalué à 9.
Pour compléter ce que tu dis...
Ce qui rend le code compréhensible par tout développeur connaissant le langage mais pas forcément les bibliothèques utilisées.
La maintenance d'une appli django est très compliquée. Les fonctionnalités de Django évoluent vite, et comme c'est basé sur des conventions qui changent/s'enrichissent, c'est très difficile de savoir ce qui est disponible et ce qui ne l'est pas sur une application donnée. Par ailleurs, les conventions et la "magie" de Django rendent des sujets a priori simples très compliqués à comprendre pour quelqu'un qui ne connait pas ou peu le framework.
Je vais prendre juste un exemple : Django propose un mécanisme de signaux pour exécuter des "triggers". C'est chouette ça simplifie l'écriture du code et tu arrives rapidement à l'objectif. Mais à lire/relire/maintenir/faire évoluer c'est une autre histoire.
Django est très bien si tu fais du pur développement web (par exemple : l'idée de réutiliser des briques de code ailleurs que dans un contexte web, c'est pas vraiment fait pour... et l'archi de Django ne t'incite pas à découper ton code en vue/logique/modèle ). Si tu es dans un environnement partiellement hors web, j'aurais tendance à ne pas partir sur un Django.
L'avantage de Django, c'est que si tu fais des choses web "classiques", tu vas hyper vite car tout est fait pour (modules disponibles, comportements par défaut correspondant à 90% des cas d'utilisation). A un moment leur tagline était qqchose comme "Django, the web application framework for projects with deadlines". En gros pour écrire vite (et si possible bien). Et ça marche bien dans ce contexte. Par exemple la gestion des migrations de modèles de base de données, les interfaces d'admin... c'est du clé-en-main. Et tu as une communauté qui créé des modules ou applications pour django qui te permettent de construire en assemblant des briques.
Mais si tu veux sortir des sentiers battus (ou prévoit de le faire), avec Django tu vas tordre ta logique de développeur pour la faire rentrer dans le moule Django et non l'inverse. Et ça, c'est pas forcément une bonne idée.
La moindre sortie de la route tracée par Django rend le code extrêmement plus complexe.
Pour compléter (ou reformuler) : un framework comme Flask va te laisser choisir les briques que tu assembles, en te proposant des solutions standards (par exemple : associer SQLAlchemy avec Flask) mais pas obligatoires. Ces solutions sont de la documentation que tu vas décider de suivre ou pas. Dans un framework comme Django ça sera inclut d'office, voire difficile à remplacer si tu veux utiliser autre chose.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo