どの場合にDjangoを使用する価値がありますか（そして、それは必要ありません）

Djangoフレームワークが次のプロジェクトに適しているかどうかを開発者が理解できるようにしましょう。 可能性が高い-適切です。



前のプロジェクトで特定のプログラミング言語またはフレームワークを使用したという理由だけで、または単にそれをよく知っているという理由だけで、特定のプログラミング言語またはフレームワークをつかまないでください。 だから物事は行われていません。



新しいプロジェクトに着手する前に、目的の結果を達成するのに最適な言語またはフレームワークを評価する必要があります。 あなたにとって最も重要なことは何ですか？ セキュリティ、開発速度、スケーラビリティ、汎用性、サポート？

後で急いで悔い改めるよりも、作業を開始する前に十分な情報に基づいて決定することをお勧めします（または、さらに悪いことに、実装の過程でプロジェクトに松葉杖を掛けます-事前にサポートを気にしなかったためです）。



私は長年にわたってさまざまなテクノロジーを使用し、モバイル開発とWeb開発の両方に取り組んでおり、Djangoは他のWebフレームワークにはない機能の完全なセットを提供すると考えています。



これは大きな声明であると理解しています。 それを正当化させてください。

「Djangoには、特にInstagramやPinterestで最も活発に使用されているサイトがたくさんあります。 Facebookでさえ、多くのユーティリティにDjangoを使用しています。 Djangoは出版環境に由来するため、このフレームワークがThe Washington PostやSmithsonian Magazineなどのサイトで使用されていることは驚くことではありません。」- Amit Ashvini 、マーケティング担当副社長@ Zibtek

一般的なビュー：Djangoを使用する場合

以下の点の少なくともいくつかがあなたに関するものである場合（そして、あなたが強く反対する点がリストにない場合）、Djangoはあなたのプロジェクトに適している可能性が高いです。

• WebアプリケーションまたはバックエンドAPIを開発する必要があります。
• 作業中にプロジェクトをすばやく展開し、迅速に展開して変更する必要があります。
• デフォルトでは、アプリケーションは最も一般的な脆弱性と攻撃、特にCSRF、SQLインジェクション、XSS、クリックジャッキングなどから保護される必要があります。
• アプリケーションではいつでも、拡張と縮小の両方のスケーリングが必要になる場合があります。
• 将来的には、機械学習などの最新のテクノロジーを統合する予定です。
• 積極的に開発され、世界中の多くのトップ企業や主要なWebサイトで使用されている信頼できるフレームワークを使用する必要があります。
• WebアプリケーションとAPIのサーバー側の両方が、「単一の真実のソース」（DRY原則）と一致する同じコードベースにある必要があります。
• データベースクエリを直接操作したくない場合、ORMサポートが必要です。
• フリーソフトウェアを使用します。
• 行き詰まった場合は、自分で解決策を探す必要があるため、優れたドキュメントと応答性の高い開発者コミュニティが必要です。

上記の要因に加えて、自分（またはチーム）のスキルを考慮する必要があります。



あなたがWeb開発者であり、Webがどのように機能するかをすでに知っている場合、Djangoとの連携は比較的スムーズに機能します。 もちろん、Djangoがどのように構成されているか、その他のことも理解する必要があります-そして、準備ができていることを考慮してください。

Djangoフレームワークで実行されているサイト

Djangoの歴史は約10年前に遡ります。 この期間中、多くのトップサイトで本番環境で使用されました。 ここにいくつかの顕著な例があります：

Pinterestエンジニアリング

Mozilla

Bitbucket

ウデミー

たまねぎ

ディスカス

ワシントンポスト

NASA

Spotify

Instagramエンジニアリング

ナショナルジオグラフィック

保護者

Jsfiddle



Djangoとの練習に貴重な時間を費やす価値があるかどうか、まだ疑問に思っていますか？ まず、Djangoがプロジェクトに適合しない理由について説明します。

Djangoを使用しない場合

• あなたは巨大なアプリケーションを扱っており、1つのコードベースに収まりません。 アプリケーションをマイクロサービスに分割することをお勧めします。 各レベルは、専任のチームによって適切に処理されます。 特定のユースケースごとに、他のテクノロジーが適しています。 これらのシナリオのいくつかでは、Djangoが便利な場合がありますが、Django（および他の個別のフレームワーク）でそのようなアプリケーションを完全に開発することは実用的ではありません。
• データベースを操作したり、ファイル操作を実行したり、少なくとも少し複雑なことをしたりする必要のない単純なアプリケーションを作成する必要があります。
  
  マイクロフレームはこれらの状況に適しています。 最も人気のあるマイクロフレームの1つ-DjangoのようなFlaskはPythonで書かれています。 同様のマイクロフレームは、他のテクノロジーでも利用できます。 PHPのSlim、JavaのApache Spark、Node.jsのExpress.jsなど
• 自分ですべてをゼロから書き、何をしているかを知りたい。
• あなたまたはあなたの同僚はDjango / Pythonにまったく慣れていないため、必要なスキルを身に付けるための時間とリソースがありません。
  
  後者の場合の最良の解決策は、あなたが最もよく知っているものを扱うことです。 新しいテクノロジーやフレームワークを採用すると、失敗する可能性が何度も高まります。

上記のすべてがあなたのプロジェクトに関するものではない場合、Djangoがあなたに合うでしょう。

Djangoを使用する理由

DjangoフレームワークはPythonで記述されています。

私はあなたがそれを知っていることを知っています。



したがって、私はこの機会を利用して、彼がPythonから継承したDjangoの主要な利点のいくつかを強調します。 簡単に説明します。



Pythonは、世界で最も人気があり、最も急速に成長しているプログラミング言語の1つです。



ソース：



TIOBEインデックス

Indeed.com JobsのCoding Dojoによるデータ分析

GitHubオクトバース



Pythonの学習は非常に簡単です。 通常、現代の開発者はこの特定の言語を最初に習得します。



上記は、この言語が初心者向けであることをまったく意味しません。 Pythonは最先端の技術でも使用されています。 Pythonは、Googleを含む多くの巨大企業の技術スタックで積極的に使用されています。



Python言語は、Webスクレイピングツールの開発に最適です。



他の言語とうまくやり取りします。



Pythonの開発は、すべてをPythonのみで書かなければならないという意味ではありません。



C / C ++ / Javaなど、他の多くの言語のライブラリを使用できる場合があります。



Pythonは移植性があり、読みやすいです。

PythonはJVM上でも実行できます。 Jythonを知ろう 。

Pythonは、ビッグデータや機械学習などの一般的なテクノロジーで広く使用されています。

巨大なPyPIライブラリにアクセスできます。

ジャンゴのオールインクルーシブ

「オールインクルーシブ」とは、Djangoがすぐに使用できることを意味し、一般的な実際の状況で必要なほとんどのライブラリとツールを備えています。 リスト：Django ORM、ミドルウェア、認証、HTTPライブラリ、マルチサイトサポート、i18n、Django Admin、テンプレートエンジンなど -それだけではありません。 私が知っている他のフレームワークは、一度にこのような幅広いサポートを提供しません。



これを「マイナス」と考える人もいれば、「プラス」と考える人もいます。 法律の両側はそれぞれ独自の方法で異なっており、ある程度は両方に同意します。



そのような状況ではフレームワークがモノリスに変わるため、これはマイナスです。



これらの機能が必要な場合、モノリスの形成につながる場合、何らかの方法で他のライブラリを使用する（または自分で作成する）必要があります。



では、これらすべてがすでに存在し、戦闘でテストされ、最大のサイトで動作し、積極的に開発され、コミュニティのサポートが提供されるツールを使用しないのはなぜですか？



Djangoが提供する機能のほとんどが必要ない場合は、マイクロフレームワークにとどまることをお勧めします。



車輪を再発明しないでください-覚えていますか？ 本当に重要なことに時間をかけ、Djangoに任せましょう。

Django管理者

前のセクションでこの要素について言及しましたが、注意が必要です。 多くのフレームワーク、特にLaravel、Yiiなどでは、管理パネルでの作業を簡素化する試みが行われています。 私はさまざまなフレームワークで多くのプロジェクトを開発することができましたが、管理パネルでの作業の利便性のために、Djangoと比較できるプロジェクトはありません。



Django Adminの柔軟性は十分ではないと考えている人もいます。その一部をニーズに合わせて微調整するには、多くの努力が必要です。 最初は、Djangoと協力して、これに同意する傾向がありましたが、時間がたつにつれて、フレームワークを理解し、それについて納得できなくなりました。 はい、独自の学習曲線がありますが、それに専念することは無駄ではありません。



実際、Django Adminは非常によく構成されています。 私のプロジェクトの中には、「そのまま」のDjango管理パネルを使用したものもあれば、ゼロから開発した独自のテンプレートに完全に置き換えたものもありました。 いずれにせよ、これは私が知っている他のフレームワークを使用した開発よりも時間がかかりませんでした。



メインプラス？ すぐにアクセス権と認証を取得できます。 このすべてをゼロから開発するには、数週間（または少なくとも数日）かかります。

乾燥原理（繰り返さないでください）

私は、支持者が「DRY」原則に本当に準拠していると主張する多くのフレームワークを知っています。 私はそのような多くのフレームワークを使用してきましたが、それらのどれにも「DRY」の原則が実装されていません。



残念ながら、ほとんどのフレームワークでは、「DRY」の原則に十分な注意が払われていません。 私の意見では、定期的に更新する予定のアプリケーション（ほとんどの最新のアプリケーションについて言えます）を書いている場合、問題を避けるためにDRYの原則に従うべきです。



そのため、Laravelでは、各プロシージャの検証を個別に記述する必要があります。 他のほとんどのフレームワークでも同じことが言えます。 コードをDRYの原則に準拠させるには、一生懸命働く必要があります。 特にチームとして働いている場合、追跡するのは難しいです。



次に、Djangoフレームワークは、DRYの原則に違反するのが通常、意図的にのみ行われるように設計されています。



そうではないはずですよね？ 例を考えてみましょう。

Djangoがデータベースの検証と移行でどのように機能するかを以下に示します

必須フィールドを使用してModel



クラスを作成します。 必要な追加の検証と制限をすべて示します。



移行は、単一のCLIコマンド「python manage.py makemigrations」によって生成されます。

変更は、「python manage.py migrate」という1つのCLIコマンドでデータベースに加えられます。

検証と制限は、CRUD操作（Django AdminまたはDjango REST Framework）のたびに自動的にチェックされます。 検証を再度記述する必要はありません。

Django Admin CRUDビューの生成には同じモデルクラスが使用されます。 カスタムHTML / CSSは必要ありません。



これらの条件を他のフレームワークと比較してください。次の数行のコードでは、このようなことは決してできないと思います。

 class Employee(models.Model): name = models.CharField(max_length=127) email = models.EmailField(null=True, blank=True) created_at = models.DateTimeField(blank=True, null=True, auto_now_add=True) updated_at = models.DateTimeField(blank=True, null=True, auto_now=True)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これは単に「繰り返さない」ことだけではありません。 このアプローチは、将来のバグからあなたを救います。 私たちは皆、ある場所で何かを変更し、別の場所で交換するのを忘れていた状況で自分自身を見つけました-そして、これは多くのユーザーが問題を抱え始めて初めて明らかになりました。



Djangoでは、上記のコードに戻り、 `max_length`



フィールドを別のものに置き換える必要がある場合は、ここで実行します。 変更は、すべてのルートの検証とデータベースに自動的に適用されます。

Djangoのオブジェクトリレーショナルマッピング

Djangoは、フル機能のすぐに使えるORMエンジンを提供します。



Eloquent、greenDAO、Yii ARなど、さまざまなテクノロジーで多くのORMツールを使用しました。 それらのすべてで、最も単純なリクエストは非常にうまく処理されますが、遅かれ早かれ、これらのリクエストまたはそれらのリクエストをゼロから書く必要がありました。



Django ORMでは、私はまだそのような状況にはありません。 データベースクエリを使用していることを忘れてしまうほどうまく機能しました。 これは、まさにオブジェクトリレーショナルマッピングのはずです。 以下に、Django ORMの例を示します。

 #  5  ,  rank = 10  age <= 30 top_young_employees = Employee.objects.filter(rank=10, age__lte=30)[:5] #      employee = Employee.objects.create(name='John Doe', age=35, country='IN') #      print(employee.name)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

迅速な開発

ほとんどすべてのWebフレームワークの作成者は、これについて自慢するのが大好きです。おそらく、「スウィフト」という言葉にどのような意味を入れるかによって、彼らは本当に正しいでしょう。



確かに、Djangoでは、いくつかのことを陽気に高速に実行します。 管理UI、データベーステーブル、および検証を簡単に決定できることは既におわかりでしょう。

それは氷山の一角にすぎませんでした。



原則として、迅速な開発は機能そのものではなく、Django DRY、ORM、テンプレートエンジン、包括的な哲学の有機的な結果にすぎません。

Django Frameworkセキュリティ

認めましょう。開発者は怠laな場合があります。 私はとても確信しています。 時々私は先延ばしにし、重要なタスクに対するソリューションを先送りにします。 これは、さまざまな脆弱性が発生する可能性がある場所です。



私は特に、Djangoが開発の速度を上げるためにセキュリティを甘やかしていないという事実が気に入っています。 セキュリティ機能はデフォルトで有効になっているため、怠けているかどうかは関係ありません。

オープンソース、優れたドキュメント、巨大なコミュニティなど

Djangoはオープンソースであり、非常に人気のあるフレームワークであるため、その周りにレスポンシブコミュニティが形成されました。 フリーソフトウェアの利点を知っていると思います-そして、それらはすべてDjangoに固有のものです。



Djangoの公式ドキュメントは、どの開発者にとっても十分です。 動けなくなっても、解決策を見つけることは難しくありません。



Djangoが独自のライブラリを多数作成したという印象を既にお持ちかもしれません。そのため、ここでテストするための特別なライブラリがないことに驚くかもしれません。 いいえ、Djangoフレームワークがテストをサポートしていないとは考えないでください。テストもサポートしています。 「繰り返さない」という原則に従えば、この種の優れたライブラリが既にPython自体にある場合、テスト用のライブラリを開発しても意味がありません。 Djangoは彼女とうまくやり取りします。 さらに、pytestなどのサードパーティライブラリと非常によく混ざります。

Djangoおよびその他の一般的なフレームワークの現状

そのため、他のフレームワークで作業しているときに発生した問題を最大限に強調し、これらのフレームワークをDjangoと比較しようと最大限に努めました。 Yii、CodeIgniter、WordPress、CS-Cart、Laravelなどと連携した後、私はDjangoがどれよりも優れているという結論に達しました。

しかし、これは私の意見です。



統計が好きな人は、Djangoが最も人気があり人気のあるフレームワークの1つである、毎年のStack Overflowの調査をご覧ください。



フレームワーク、ライブラリ、およびツール

最も愛され、恐れられ、欲しかったフレームワーク、ライブラリ、およびツール



PHPでの上記の経験に加えて、JavaのAndroidアプリケーション、React.jsのクライアントアプリケーションも開発しました。 これらすべてのケースで、スケーラビリティに問題が生じてリファクタリングを再開してから数か月後に、コードベースのリファクタリングにかなりの時間を費やし、最適なアーキテクチャを探しました。



私は最近、LaravelからDjangoに、1年以上生産していた1つのアプリケーションを書き直しました。 私は10日以内に新しいコードベースを展開し、このために最小限のコードを記述しました（同じことを言います：複雑さが減ります！）反対の方向では、このような操作は間違いなく1か月以上かかります。



他のフレームワークとDjangoを直接比較しようとしても、何も得られません。

パフォーマンス監視により、JavaフレームワークがDjangoよりも高速であることが示される場合があります。 PHPが得意であるため、Djangoでのアプリケーション開発は、使い慣れたPHPフレームワークを使用する場合よりも高速になる可能性があります。 非常に単純なアプリケーションの場合、Djangoのセットアップは少し面倒に思えるかもしれません。もちろん、スクリプトを使用してファイルを作成する方がはるかに簡単です。 調査結果は、実施された対象者によって異なる場合があります。



ただし、ここでは、他の技術に関連するフレームワークについてのみ説明しているわけではありません。 Pythonに精通していても、Flaskマイクロフレームワークの方が便利で望ましい場合があります。 あなたはどちらで立ち止まるかについて考える必要があります。

私のアドバイスは単にそれらを比較しないことです。

おわりに

私の意見では、Djangoはパフォーマンス、アーキテクチャ、開発の複雑さ、セキュリティ、およびスケーラビリティのバランスをうまくとることができました。



プロジェクトをゼロから書き始めている場合は、Djangoを使用して作成することを強くお勧めします。