ホームページ  >  記事  >  PHPフレームワーク  >  Drupal と thinkphp を比較して国内のオープンソース環境を確認

Drupal と thinkphp を比較して国内のオープンソース環境を確認

青灯夜游
青灯夜游転載
2021-09-29 19:50:042753ブラウズ

今日は、この記事で ThinkPHP と Drupal を比較し、中国と海外のソフトウェア産業の現状と国内のオープンソース環境を見ていきます。

Drupal と thinkphp を比較して国内のオープンソース環境を確認

住宅、結婚、医療、教育、介護、それぞれが大きな山であり、「お金を稼ぐ」ことが最優先であり、誰がオープンに取り組む暇があるのか​​。ソース?そのため、たった2人のコア開発者によって作られたThinkPHPは、多くの人々の希望となっていますが、その一方で「若者の食べ物だけを食べるプログラマー」は存在しません。 「彼らはまだ目に微笑みを浮かべている。テクノロジーについて話し、人生の意味を探しており、生計にあまり邪魔されていない。彼らは人生の蓄積をオープンソースに注ぎ込んでいる。彼らは自分たちのやっていることによって世界を照らし、社会を変えることができると夢見ている」人類文明に受け継がれる偉大なる作品に命を吹き込んだDrupalは、皆から称賛され、瞬く間に星の海へと旅立っていきました。この文章は、同じ文章を読んだ人がどこへ行くのかを考える悲しい物語であり、より多くの人に知られるべきものです。

ThinkPHP と Drupal を比較して中国と海外のソフトウェア業界の現状を確認してください

ThinkPHP と Drupal (中国語では「水滴」と訳される) を組み合わせると、この話は多くの開発者を惹きつけるでしょう 読者は興味を持っていますが、中国と外国のソフトウェアエコシステムの発展の観点から見ると、これは議論の良い出発点です この記事では、さまざまな側面で 2 つのシステムをいくつか比較しましたが、比較はこの記事を書く主な目的はありません。主に中国と外国の間で情報を共有することです。ソフトウェア業界の違いと、そこから生じる考えのいくつかは、開発者がキャリアを計画するのに役立ち、ソフトウェア業界の意思決定の基礎を提供します。 IT 意思決定者。

両方のシステムはオープンソースの無料 PHP アプリケーションです。最初に簡単に紹介しましょう:

ThinkPHP:

製品位置付け: PHP 開発フレームワーク、開発者はこれに基づいて独自のアプリケーション システムを開発および構築し続けることができます

開発組織: 国内の「上海鼎祥信息技術有限公司」が開発します

創設者: Liu Chen, あまり情報がありません. Baidu Query はオープンソース ソフトウェアのシニア コンサルタント、シニア PHP プログラマー、Kanyun の CEO です. 彼はインターネット製品の開発と管理に 15 年以上の経験があります. 彼の主な研究分野には、Web アプリケーションのアーキテクチャと開発、製品のユーザー エクスペリエンス デザインが含まれます。国内のオープンソース業界に注力しています。

開発時期: 2006 年初めに初めて誕生しました

オープンソース プロトコル: Apache 2

公式 Web サイトのアドレス: http://www.thinkphp.cn /

ユーザー グループ: 国内の開発者界で高い評価を得ている中国国内の小規模企業、公式 Web サイトにはその旨が記載されています「中国で最も影響力のある PHP フレームワークおよびパイオニア!」として評価

有名な事例: 56 グループ、Lenovo Wenba、CYTS Happy Travel、ポカリスエット、スターバックス、Metersbonwe の Bangou Mall、TCL のオンライン モール、Sina WeChat、Aoxing、 CRRC You Technology 他

チームの規模: 公式データはありませんが、フレームワークの各ファイルには作成者情報が含まれています。この統計によると、主要な開発者 2 名を含む合計 7 名です (より多くの貢献を行っています)コードの 90% 以上). これらのデータには、コミュニティ エコシステムに貢献した開発者は含まれていません. Qichacha プラットフォーム上の Dingxiang Company のクエリ結果によると、会社の規模は 50 人未満で、被保険者の数は3. システム ファイル: 現在の 6.0.7 カウント バージョンによると、最初にインストールされるファイルの数は 569 で、占有スペースは 2.41MB

Drupal: 製品の位置付け: 完全なバックエンド システム (バックエンド システム、エンド データおよびコントロール センター)、APP、小規模プログラム、Web サイト、モノのインターネットなどのバックエンド開発に使用されます。

開発組織: 世界 200 か国以上が共同構築し、Drupal Foundation によって組織される非営利のオープンソース コミュニティ

創設者: ベルギーの Dries Buytaert 博士によって設立されました。Dries の 2008 年大学の博士論文は「Java アプリケーションのパフォーマンス分析と最適化分析テクノロジ」でした。Java の発明者である James Gosling 氏は博士防衛委員会のメンバーです。Dries 氏の個人ホームページのアドレスは https://dri.es/about## です。

#開発時期: 2000 年に初めて誕生

オープンソース契約: GPL 2.0

公式 Web サイトのアドレス: https://www.Drupal.org/

ユーザーグループ: 世界中の企業、政府機関、大学、個人など、その中で世界上位 500 社の市場シェアは 80% を超えています 有名な IDE: phpstorm は新しい Drupal プロジェクトを直接統合します

有名な事例:国内:Huawei、JD.com、Baidu、Tencent、清華大学、北京大学、貴州市政府駅集団、鎮公府など、海外:Tesla、Google、Honda、Qualcomm、国連、欧州連合、ハーバード大学、 MIT、ディズニー、NASA、ファイザー製薬など

チームの規模:

は世界で最大かつ最も活発なオープンソース コミュニティを持ち、1,800 人以上のコア開発者と 120,000 人以上の開発者がいます。中国のサブコミュニティの 2,000 人以上を含む積極的な貢献者 (コード、ドキュメント、デザイナーなど) がおり、主要な推進会社である Acquia には 1,100 人を超える従業員がいます。現在、週に平均約 1,300 件のコードが送信されます。

システム ファイル: 現在の 9.1.7 バージョンに基づくと、最初にインストールされるファイルの数は 18,770 で、71.2 MB のスペースを占有します

ThinkPHP と Drupal を使用する理由:

1 つは中国で人気のあるフレームワークで、もう 1 つは国際的に人気のある完全なバックエンド システムです (これは世界で最も強力で柔軟なシステムでもあります)。 「Drupal はまったく同じ重量クラスではありません。市場での位置付けの観点からは、比較する意味はありませんが、これらを調査することは、中国と外国のソフトウェア生態を理解する上で非常に重要です。また、Drupal を直接あなたに伝えたらどうなるでしょうか。」 ThinkPHP でできることはすべて実行でき、さらにエレガントで簡潔ですか?話が面白くなってきたので、続けてみましょう。

通常、Drupal を使用する国内の開発者は長年の開発経験を積んだベテランであり、時代とともにさまざまなシステムから一歩ずつ出てきており、ThinkPHP についてはある程度の知識や理解が必要ですが、ThinkPHP を使用している開発者は、 ThinkPHP を使用する開発者が ThinkPHP を選択する理由は、一般に、このフレームワークが基礎となる PHP よりもさらに共通の基盤を提供し、柔軟性があり、無料であり、Imperial のようなシステムの二次開発と比較して制限がないためです。 CMS. 独自の機能を自由に実装できますが、Drupal の前では状況が異なり、開発者にとっては宝物を見つけたような気分になるかもしれません. ここで、Drupal のシステム アーキテクチャについて簡単に紹介します。 Drupal システム全体層で構築されています。の:

最下層:

は、人気のある Symfony フレームワークに基づくフレームワーク層です。Symfony は、PHP の業界標準であり、最も有名なフレームワークであると言えます。世界のフレームワークです。もう 1 つの有名な PHP フレームワークは、Laravel 自体です。多くの部分も Symfony に基づいているか、Symfony から来ています。Symfony フレームワークを知っている開発者はすぐに Drupal の開発を始めることができます。Symfony フレームワークの作者である Fabian は伝説的な人物です。」彼のよく知られた作品のもう 1 つは、Twig テンプレート エンジンです。これも Drupal を使用しています。Drupal は Symfony の最も有名な例であり、公式 Web サイトでは Drupal が最初にリストされており、Drupal コミュニティも Symfony コードの寄稿に参加しています。

第 2 層:

はデータ層であり、エンティティによって表され、さまざまなデータを上方に提供します。データベースのカプセル化はこの層に属します。ORM の概念と ThinkPHP のモデルの概念は次のように似ています。エンティティの概念 非常に初期の頃の様子

3 番目の層:

アプリケーション層、開発者はこの層でさまざまなビジネス ロジックを処理します

ここで開発者は料金を支払う必要があります注意 Drupalを使用する場合、レイヤーごとに呼び出す必要はなく、スキップして特定のレイヤーに直接進むことができるため、フレームワーク層を直接開発する場合、システム全体をフレームワークとして利用することができます。 , ThinkPHP の開発と同じです。ThinkPHP フレームワークを直接使用するのと同じです。そのため、Drupal は ThinkPHP で実行できるすべてのことを行うことができます。違いは、Drupal が Symfony フレームワークを使用していることです。余談ですが、ThinkPHP は Symfony の影響を深く受けており、さらにSymfony のコンポーネントの一部を直接採用しており、多くの点で Symfony フレームワークを高度に活用しています (どの作成者も尊敬に値するため、「盗作」という言葉は使用されませんが、「借用」という言葉が使用されます)。画像の説明:

人間の祖先が結び目のあるロープを使って数を数えていた頃、果物は果物であり、魚は魚でした。背後にある数字の「1」がそれぞれの具体的なものから抽象化されたとき、人類は大きな飛躍を迎えました。この瞬間の重要性は、火の使用、数字、数学などの発明に劣りません。人類は常に世界を探索し、抽象化して才能を積み重ねてきましたが、今日の文明においては、抽象度が高くなればなるほど、その意味はより強くなり、より本質に近づくと言えます。 。

優れた作品の多くは蓄積に膨大な労力と時間を必要とします。では、ThinkPHP と Symfony の間、または ThinkPHP と Drupal の間の蓄積の差はどれくらいあるでしょうか?ここで直接的かつ決定的に言えることは、小学校と大学の間には中学校と高校があり、その間にギャップがあるということですが、その主な理由はコミュニティの規模、生態系、時間にあります。 ThinkPHP と Symfony はどちらもフレームワークであり、最も直接的な競合相手です。ThinkPHP が存在するためには、独立したイノベーションの道が必要ですが、Symfony から多くのものを借用しています。これは非常に恥ずかしいことです。開発者として、なぜそれを直接使用しないのでしょうか?シンフォニーについて?同レベルのCIフレームワーク(CodeIgniter)は完全に独自に開発されており、多くの世界ランキングではThinkPHPの影が見えないが、中国では多くの採用情報でThinkPHPの影が見られるなど、非常に優れたサービスである。 ThinkPHP は完全なローカル製品であるため、注釈ドキュメントも中国語で書かれていますが、これを踏まえて、この記事では中国および外国のソフトウェアの状況を研究する出発点として ThinkPHP を選択しています。

良いシステムとは何でしょうか?私たちは何が必要なのか?

ことわざにあるように、仕事をうまくやり遂げたいなら、まずツールを磨く必要があります。優れたシステムがどのような特性を持つべきかを説明するためのいくつかのポイントを以下に示します。これらを使用して ThinkPHP と Drupal を比較します:

完全性:

いわゆる完全性とは、あらゆる状況を考慮して設計されたツールやコンポーネントであると考えることができます。たとえば、PHP がネイティブで提供する文字列インターセプト機能では、UTF-8 文字が切り捨てられ、文字化けが発生します。あなたが設計したインターセプト関数は、これを行わないだけでなく、英語の単語を切り詰めることもありません。また、HTML 内のタグが切り詰められないことも考慮されています。そうすれば、ツールは PHP ネイティブ関数よりも完全になります。満足できない列がある場合は、改善する必要があります。完全性の向上。Drupal の多くの部分の設計は「完成」しています。Drupal は探究と進化を続けていますが、この完成度のレベルは ThinkPHP をはるかに上回っています。たとえば、Drupal のルーティング システムは、ドメイン名、プロトコル、HTTP メソッド、データ形式、オプションなどに基づいて自然にサポートされます。それらがすべて一致する場合、優先順位が分類されます。これらは ThinkPHP では完全には利用できません。このコンポーネント設計の完全性は、深さに依存します。トランザクションの性質の理解と大量の開発経験の完全性により、人類は先人たちに基づいて前進し続けることができます。

標準化:

標準化は大規模コラボレーションの前提条件であり、システムの階層構造、システム間通信、分離されたコンポーネントなどはすべて標準化から切り離せません。 Drupal は完全に RFC を重視しています。ドキュメントは自己完結型のシステムではありません。コメントやディスカッションで RFC への参照がよく見られます。RFC ドキュメントは IT インターネットの基礎です。製品に共通の国家標準に似ています。RFC ドキュメントは、多くの場合無視されます。ユーザーですが、非常に重要です。

整合性:

協力的な分業。開発された完成したコンポーネントがまとめられ、全員がそれを使用すると、これが完全性を構成し、その場合、人は作業を行う必要がなくなります。車輪そのものを再発明し、巻き込みを打破する 整合性が完成度の向上を促進する Symfony と Drupal は、コンポーネントとモジュールの形で整合性の問題を解決します。

低結合:

各コンポーネントに開発と改善の余地を与えるために、システム設計の各コンポーネントをできる限り分離する必要があります。コンポーネントの交換も容易です。Drupal はモジュール設計を採用しており、コアもモジュールです。ユーザーは、機能不足やアップグレードの妨げを避けるために、直接変更することなく、ユーザー空間内のコア ファイルを置き換えることができます。比較的言えば、ThinkPHP は密結合です。

境界をマスターする:

優れたシステムとは、適切に制御されたシステムでなければなりませんが、これは実際には少し難しいことです。また、慈悲深い人々は、善意と善意について異なる見解を持っています。賢い人にはさまざまな意見があります。一般的に言えば、一般的な方向またはバックボーン システムは簡潔でなければなりません。これが例です。ThinkPHP は、ルーティング パラメーターに基づいてルーティング コントローラーの決定をサポートしています。つまり、 Route::get(':action/blog/:id ', 'Blog/:action' );、Drupal ではこれが許可されていません。同様の機能を実装する場合、通常はプロキシ コントローラーが使用されます。つまり、この効果はルーティング レベルで実装されるべきではなく、コントローラーで実装される必要があります。これにより、ルーティング システムがより簡潔になります。システム アーキテクチャがより明確になります。この考え方が Drupal に貫かれており、Drupal システムのバックボーンが非常にシンプルでクリーンになります。詳細な機能が必要な場合は、最初に対応する大き​​なトリビュタリを入力してから、次を入力してください細かい支流が色々あって、まるで木のようですか??しかし、どちらの方法が好みですか?

シンプルさ:

シンプルに言うと、システムには明確なプロセス、統一された呼び出し、一貫したルールが必要であり、余分なものは許可されない、または余分なものは可能な限り回避する必要があります。この利点は、初心者にとっても学びやすく、追跡とトラブルシューティングが非常に便利であることです。

活力:

システムの活力は持続可能性にもあり、エコシステムと開発者はシステムの栄養源であり、これについては後述しますが、ここでは省略します。

ThinkPHP と Drupal の比較:

ThinkPHP と Drupal を比較すると、一般的に、ThinkPHP には抽象化と蓄積が不十分です。欠点は、子供に似ているということです。Drupal は何年も経験を積んだ大人です。彼はより多くのことを知っており、物事の背後にある一般原則を知っており、さらに先へ進みました。建物を建てていると仮定してください。コンクリートは ThinkPHP が提供します。レンガ、鉄骨バーやその他の基本的な建築材料を使用する場合、開発者は構築方法、設計方法、その他の建築上の問題を検討する必要があります。Drupal は基本的な材料を提供するだけでなく、建設チームや設計機関も付属しています。多くの場合、「あなたはただ」と言うだけで済みます。あなたが望むどんな雰囲気や機能をもった建物を建てる必要があります (あなたが満たしているニーズは通常、他の人によって満たされており、インストール可能な多数の貢献モジュールを形成しています) もちろん、興味があれば参加することもできます。このプロセスにより、カスタマイズされた結果が得られます。

この章では、技術アーキテクチャのレベルで 2 つを比較します。開発者でない場合、または特定のテクノロジに興味がない場合は、この章を直接スキップして次の章に進んでください。ここでは、最新のThinkPHP のバージョン 6.0.7 と Drupal 9.1.7 が使用されています。スペースが限られているため、いくつかの重要なコンテンツのみが比較のために選択されています:

イベント:

ThinkPHP では、イベントは本来の動作やフックの仕組みを置き換える位置付けになっています。イベントとフックの本質的な違いを作者が理解していないことがわかります。同じ点は、サードパーティのコードが介入するために使用されているという点です。現在のロジック処理。しかし、この一般的な前提の下では、フックは参加に焦点を当て、イベントは通知に焦点を当てます。それらは量と性質において大きく異なります。ThinkPHP はそれらを混乱させますが、Drupal はそれらをより本質的に理解しています。ThinkPHP には、 「イベント」という概念は、実装が緩くて複雑であり、大きな機能的欠陥があります。たとえば、ThinkPHP イベントには優先順位の概念がありませんが、これは順序要件がある場合に重要です。イベント伝播終了メカニズムはありません。たとえば、ThinkPHP はイベント クラスの実装を必要としません。実際、イベントを処理するには、通常、パラメーターを渡す必要があり、処理結果をイベントのソースにフィードバックする必要があります。したがって、イベント クラスが必要です。ThinkPHP は非常に基本的なもので、Drupal はイベント ディスパッチャー サービスを使用してすべてのイベントを処理し、サブスクリプションを実行します。プロセッサとリスナーには特別な制限はありません。システム内の任意の場所でイベント関連のロジックを処理するには、必要なのは、イベント ディスパッチャ サービスに直面するために

#ミドルウェア:

In ThinkPHP と Drupal にはどちらも「ミドルウェア」という概念がありますが、その位置付けは大きく異なります。ミドルウェアによって実装された機能は、Drupal のイベント ディスパッチャによって処理されます。たとえば、ThinkPHP ドキュメントでは、アプリケーションの HTTP リクエストをインターセプトまたはフィルタリングするためにミドルウェアが主に使用されると述べています。これが、Drupal でリクエスト イベントのディスパッチを行うことです。また、ルーティング ミドルウェアとコントローラも同様です。ミドルウェアも同様です. これらはルーティング イベントとコントローラー イベントに対応しており、Drupal のミドルウェアに相当します ソフトウェアの主な機能は、HTTP 処理コアを 1 つから複数に変更することです. 論理アーキテクチャの点では、Drupal の方がはるかにエレガントであり、 ThinkPHP よりも明確です。これは、ThinkPHP がイベント メカニズムを十分に理解していないことも原因で、システム構造が乱雑になり、将来のアップグレードに適した環境が提供されます。負担は埋もれています

エントリ ファイル:

両方のエントリ ファイルは非常にシンプルで、ロジックは比較的似ています。主な違いは 3 つあります:

1. Drupal はエントリ内の処理コアにリクエスト オブジェクトを直接挿入します。ファイルは文字通り「どんなWebシステムもリクエストをレスポンスに変換するシステムである」という概念を反映したものであり、ThinkPHPのHTTPサービスのrunメソッドも利用可能ですが、入口では反映されませんが本質的な違いはありません大きな違いは、ThinkPHP には「サブリクエスト」機能、つまり、システムの実行中に処理のためにリクエストを送信する機能がサポートされていないことです。システムから飛び出して戻ってくる必要はありません。 , この機能はシステム アーキテクチャに大きな影響を与えます (システム全体を通じて、サブリクエストはメイン リクエストの環境ステータスに影響を与えるだけでなく、パフォーマンスも考慮する必要があります)。この点は、Drupal のシステム アーキテクチャがはるかに強力であることを最もよく示しています。 ThinkPHP よりもはるかに優れており、Drupal は複雑なビジネス ロジックをより適切に処理できます

2. 真のシンプルさ、Drupal には、複数のアプリケーションであっても、単一のアプリケーションのフロントエンドとバックエンドであっても、グローバルにエントリ ファイルが 1 つしかありません。 1 つだけ ユーザーは複数のエントリを設定できますが、複数のエントリはお勧めできません。これにより、複雑さが軽減され、シンプルさが保たれ、URL エイリアス システムの基礎が築かれます。ThinkPHP には、特に複数のアプリケーションを使用する場合に、複雑な複数エントリのメカニズムがあります。これは次のとおりです。 URL エイリアスのサポートにも役立ちますが、より困難になります

3. Drupal は初期状態でクラス ローダーをプロセッシング コアに渡し、クラス ローダーの置き換えや変更を当然サポートしますが、ThinkPHP はそれをサポートしていません。をロードするだけでは、クラスローダーを変更する必要があるときにクラスローダーを取得できず、柔軟性が大幅に低下します。たとえば、多くのクラスはユーザー独自のものに置き換えることができません。たとえば、「」を置き換えたい場合は面倒です。 \think\Http」クラス。

複数のアプリケーション:

どちらも複数のアプリケーションをサポートしています。つまり、複数のシステムが同じコード セットを再利用しますが、特定のメソッドという点では Drupal の方がはるかにシンプルです

インターフェイス指向プログラミング:

ThinkPHP の多くの実装では、インターフェイスはクラスから抽出されず、一部の重要なクラスでさえインターフェイスがありません。たとえば、次のとおりです。

\ think\App

\think\Request

これらは非常に核心的で重要ですが、独自の独立したインターフェイスを持っていません。ThinkPHP はインターフェイスに従って厳密にプログラムされているわけではありません。これにより、柔軟性が大幅に低下します。たとえば、\think\App を置き換えるために独自のアプリ クラスを実装したいのですが、それができません。変更できるのはコアのみなので、毎回アップグレードするのは問題です。Drupal では、インターフェイスに厳密に従っており、アーキテクチャはインターフェイスとパラメータの型に完全に準拠しています。制約はすべてインターフェイスです。最も重要な HTTP コア クラスである DrupalKernel を含め、コアを変更することなく、コアによって提供されるクラスを置き換えることができます。 ThinkPHP アプリ クラスに似ています。

インターフェイス プログラミングに厳密に従わないと、スケーラビリティに影響するだけでなく、IDE にとって不親切、ドキュメント抽出の自動化が難しい、コード コメントが継承されない、共同でのディスカッションが不便になるなど、他の多くの欠点も生じます。

ルーティング システム:

ThinkPHP 公式チュートリアルの原文を引用:

「ThinkPHP はルーティングの使用を強制されません。ルーティングが定義されていない場合、 "Controller/ Operation "Access" を直接使用できます。

フレームワーク作成者がルーティングの本質を十分に理解していないことがわかります。前述したように、番号 1 が抽象化されていません。いわゆる " 「controller/operation」メソッドもデフォルト ルートに属している必要があります。または、内部パス ルーティングの一見無害な点は、ルーティングがないのではなく、実際には非常に重要であり、本質的な認識が必要であり、これにより大きく異なる動作が生じます。

ルーティングは、システムに入った後の分かれ道であり、存在する必要があります。権限制御、パラメータ変換、パス エイリアス処理、言語処理など、多くのビジネス ロジックをここで処理する必要があります。ThinkPHP には、さらに、そのような認知結果により、コードの冗長性や一貫性のない使用など、物事が必然的に緩くなり、複雑になります。

エントリ処理は、ルーティングの 2 つの主要な機能のうちの 1 つにすぎません。もう 1 つの主要な機能は、システム全体の URL の生成である出口処理です。これは、URL エイリアス処理、言語ネゴシエーション、SEO、などがありますが、ThinkPHP には単純な実装しかなく、ルーティング システムの役割が完全に実現されていません。たとえば、次のような要件があります:

ユーザーが "target="_blank"" を追加します。カスタム関数でシステム全体の URL を取得するにはどうすればよいですか?

コンテナと依存関係の注入:

この概念と名前は Symfony フレームワークに由来しています。詳細については、

https://symfony を参照してください。 com/doc/current/components/dependency_injection.html

つまり、主なアイデアは、システム内に中央の大きなオブジェクト (親オブジェクトとも呼ばれる) をセットアップすることです。オブジェクト. Symfony では、この大きなオブジェクトはコンテナと呼ばれ、その中に保存されるオブジェクトはサービスと呼ばれます. サービスの定義は YAML で静的に提供することも、サービスを通じて動的に提供することもできます「定義」には一定の形式がある サービスが必要な場合、コンテナオブジェクトは定義に従ってサービスオブジェクトをインスタンス化し、保存して返します 定義にはクラス、パラメータ、ファクトリメソッド、ポストなどの概念が含まれます-インスタンス化コールバック、コンフィギュレーター、パブリックおよびプライベート プロパティ、機能の継承、遅延インスタンス化など コンテナーの形成前に、サービス グループやパラメーターの変更などの高度な機能を処理するためのサービス コンパイル プロセスがあります。コンテナー内の各サービスには、サービス ID と呼ばれる ID 使用時にこの ID を介してサービス オブジェクトが取得されます コンテナ内には、サービスの保存に加えて、コンテナのパラメータ、サービスのエイリアスなども保存されます。

ThinkPHP のコンテナ概念には Symfony の影がありますが、まだ非常に新しく初歩的なものです。その実装は単純さからはほど遠く、混乱を招きます。たとえば、サービス ID やサービス オブジェクトといった明確な概念はありませんSymfony コンテナーには、対応するサービス ID が存在する必要があり、ThinkPHP は同様の概念抽象を呼び出します。これは識別子またはクラス名にすることができますが、一部のコンテナー メソッドはそれをクラス名として使用します (例:

##) #\think\ App::register

\think\App::getService

作成者は可能な限り柔軟にしたいと考えているようですが、矛盾による混乱を引き起こします。 ThinkPHP における「サービス」の概念 (オペレーティング システムのサービスに似た) 別の定義がありますが、基本的には Symfony のサービスですが、特別な処理が必要です。Symfony では、サービスをコンテナに入れることを「収集」と呼びます。 " サービス、つまりサービスをコンテナに "注入" します。ThinkPHP では、サービスをコンテナに "バインド" と呼びます。名前が示すように、コンテナは物を保持するために使用されます。なぜバインディングと呼ばれるのでしょうか?この種の名前は発音が非常に難しく、意味が伝わらない名前もたくさんあります。たとえば、ThinkPHP では、実行中のコンテナ内のオブジェクトのインスタンス化後の操作を、「実行後」操作ではなく「実行後」操作と呼びます。コンピュータ業界には有名な格言があります。「難しいのは何ですか? キャッシュと名前付けです。」ThinkPHP はこの分野で改善する必要があります。現在の名前付けの一部は初心者にとってフレンドリーではありません。

さらに、サービス (ThinkPHP では、コンテナにバインドされたクラス、オブジェクト、またはコールバックと呼ばれます) もサービスをコンテナにバインドできます。この機能は柔軟性があるように見えますが、コードの追跡やデバッグには非常に不便です。 Drupal は、そのモジュール設計の恩恵を受けており、一元的な宣言が可能です (モジュールは、サービスがどのサービスに依存しているかを認識する必要があり、コンテナーのコンパイル メカニズムは、サービスが依存しているかどうかも判断できるため)存在します)。そのため、コードの追跡とデバッグが可能な限り簡単になります。また、実際に各サービスをインスタンス化せずに、ランタイム コンテナー内のサービス定義をエクスポートすることも便利です。

ファサード:

これは ThinkPHP の概念であり、パッケージ化されたクラスの動的メソッドを静的に呼び出すために使用されます。つまり、静的メソッドを使用してクラスをプロキシします。クラスをメソッド レベルに変更すると、これは単なる形式的な調整であり、オブジェクトは依然として内部でインスタンス化される必要があります。実際、この概念は必要ありません。IDE にとって非常に不親切なだけでなく、PHP static の本来の意図にも違反します。メソッド設計。ThinkPHP のコンテナ機能の不足を補うだけです。Drupal にはそのような概念はありません。その機能的な目的は、\Drupal::service($id) 静的メソッドを均一に使用してサービス インスタンスを取得し、その後開発者は動的メソッドを自分で呼び出すことができ、別のインスタンスが必要な場合は、それを自分で複製することができるため、プロキシ クラスの導入に伴う問題の使用も回避できます。

アシスタント機能

ThinkPHPにはアシスタント機能という概念があり、その目的はIDEからの自動リマインダーの利便性を享受することであるとドキュメントに記載されています。 "\ "Drupal" グローバル クラスは静的メソッドやショートカット関数を提供しますが、Drupal は IDE のためではなく、PHP 関数や静的クラス メソッドがスーパーグローバルに利用できるため、サービスを取得する方が便利だからです。

コントローラーとモデル:

ThinkPHP では、コントローラーはビジネス前処理ロジックを実行するために使用されると考えられています。コントローラーは PHP クラスまたはクロージャーである必要があります。ビジネス ロジックは「パターン」の問題です。実際、これは非常に厳密です。まず第一に、コントローラー それは、関数、コンテナー インスタンス メソッド (コンテナー ID で定義) などを含む、任意の形式で表現される PHP コールバックにすることができます 第二に、実際には、ビジネス ロジックの境界はそれほど明確ではありません、そして、「パターン」を抽象化してこれに名前を付けるのは困難です、繰り返しになりますが、コントローラはすでに業務処理の開始点であるべきであり、ThinkPHPの概念におけるコントローラが行うことはルーティングで処理されるべきです。ThinkPHPはすでに実現していますこれについては文書で言及しました。

多言語処理:

実装に関しては、ThinkPHP と Drupal は両方とも開発メタ言語として英語に基づいています。ThinkPHP の翻訳実装は非常にシンプルで、特に国際的なアプリケーションを開発する場合 (これはアプリケーションのカバー範囲が不十分であることが原因です)、Drupal には完全な多言語システムがあり、次の概念を完全に処理しています:

言語単数形と複数形の問題(一部の言語は単数形と複数形を超えています) 文脈上の問​​題(「may」は「can」または「May」と翻訳されますか?) 翻訳インターフェイス、JS のテキストの構成およびコンテンツ言語、翻訳左側のテキスト言語のコラボレーション メカニズムなど。

ThinkPHP にはこれらがありません。単にテンプレート内のテキストの翻訳とステートメント内の変数の置換を実装するだけです。さらに、Drupal には当然複数言語ネゴシエーションがあります。ユーザー設定、URL プレフィックス、セッション情報、ドメイン名、HTTP ヘッダー、ユーザー エージェント識別子などのメカニズムをサポートし、プラグインによる言語ネゴシエーション メカニズムのカスタマイズをサポートします。デフォルトでは、ThinkPHP は URL、HTTP ヘッダー変数、 Cookie とブラウザ。言語情報の転送に Cookie を使用する場合、国際的なシステムを開発する場合にそれが可能になる可能性があることに注意してください。法的問題が発生します。多くの国では、システムがユーザーに Cookie を使用できるかどうかを明示的に尋ねることを要求しています。要約すると、 ThinkPHP を使用する場合、開発者はほとんどの言語問題を自分で解決する必要がありますが、実際には多言語システムがシステム全体で動作しており、非常に大規模かつ複雑です。Drupal は国際的に共同構築されたシステムです。 -言語はそのハイライトの 1 つであり、自然な多言語システムですが、これだけでも ThinkPHP 開発者を困惑させる可能性があります。

キャッシュ システム:

完全なキャッシュ システムには、有効期限、有効期限タグ、コンテキストの 3 つの要素があります。Drupal にはその完全な実装がありますが、ThinkPHP には実装されているのみです。 time と Tags はコンテキストを実装していません。では、コンテキストとは何でしょうか?簡単に言うと、同じキャッシュキーKEYの下で、キャッシュされたオブジェクトが誰に属し、どのような環境下にあるのかを示すもので、例えば、ユーザーの権限、ログイン状態、言語、IP、プロトコルのバージョン、トピック情報などがすべてキャッシュに属します。これは大規模なシステム設計にとって重要であり、システムが非常に大きいため、開発者はキャッシュ コンテキストの問題を自分で解決する必要があります。さらに、ThinkPHP では、キャッシュ マージ メカニズムが提供されていないため、効率的なキャッシュを実現するために不可欠な階層キャッシュ処理が可能になりません。

セッション:

ThinkPHP を使用する開発者は、セッション関連の問題を自分で解決する必要があります。今日の IT の発展により、小規模およびマイクロ システムのみが 1 台のサーバーのみを使用し、ほとんどのシステムは複数のサーバーに負荷を分散します。そのため、アプリケーションはステートレス性を必要とするため、セッション データをローカルに保存することはできません。通常の解決策は、ベースに基づいて保存することです。これは、ThinkPHP がセッションのデータベース保存のための既存のソリューションを提供できないフレームワークであるため、開発者が自分で処理する必要があるためです。Drupal 自体は負荷分散やアプリケーションのステートレス性などを考慮しており、セッションは次の方法でデータベースに保存されています。デフォルトです。すぐに使用できます。ThinkPHP は拡張機能を備えていますが、開発者は開発を実装するために多額の人件費を支払わなければなりません。

ThinkPHP のセッション実装に問題があります。セッションは保存されません。スクリプト終了後ですが、スクリプト内で実行されるため、ユーザーが die または exit を呼び出しても保存されません。shutdown 関数を登録する必要があります。詳細については、php 関数を参照してください:

register_shutdown_function

Database:

ThinkPHP と Drupal はどちらも複数のデータベースをサポートしています。ThinkPHP は、この機能を説明するために「分散データベース」という概念を作成しました。Drupal には特別なレンダリング概念はなく、は、異なるデータベースを区別するためにビジネス識別子のみを使用します。どちらも、マスター/スレーブ構成と読み取り/書き込み分離もサポートしています。しかし、実装の点では、Drupal の方がはるかに洗練されているのは明らかです。たとえば、データベース構成のデータ構造では、 Drupal は多次元配列を使用します。第 1 レベルのキー名はビジネス識別子、第 2 レベルのキー名はビジネス識別子です。レベルのキー名はマスター/スレーブの識別子、その値は接続構成情報ですこの構造は非常に単純です。データベース ロード スケジューリング サブシステムを実装する場合、この構造のインターフェイスは非常に単純で、ThinkPHP の構成データ構造では、すべてのホスト アドレスを 1 つの配列キーに保存し、すべてのパスワードを別の配列に保存します。このような構造では、接続情報を生成するときに構成情報を再度解析する必要があります。読み取りと変更が直観的ではないだけでなく、システムのパフォーマンスを消費します。データベース負荷スケジューリング サブシステムのインターフェイスは次のとおりです。複雑で非常に洗練されていません。

どちらも複数のタイプのデータベースをサポートしています。Drupal のコアには、mysql、pgsql、sqlite の 3 つのデータベースがサポートされています。さらに、コミュニティ モジュールでは、一般的に使用されるすべてのデータベースがほぼ完全にサポートされています。異なるデータベースを組み合わせる この違いを「方言」と呼びます 異なる方言の処理はドライバ層で完結し、上位層への統一インターフェイスを提供します つまり、上位層のデータベース操作クラスは、どのデータベースがどの時点で使用されているかを認識できませんモジュール開発者は、データベースの分離が実現されており、ユーザーがどのデータベースを使用しているかを考慮する必要がありません。テーブルの作成、クエリ、変更などはすべて実行されます。アプリケーション層で異なる種類のデータベースを切り替える場合、ワンクリックで切り替えることができます。

データベース操作に関しては、Drupal は完全なシステムであるため、非常に高度なデータ ストレージ構造のセットがデフォルトで実装されています。この構造は、システム データ層のサポートを提供します。全員が統一されたデータ構造に基づいている場合, 素晴らしいことが起こりました。世界中に分散した人々が協力して、リッチな上位レベルのアプリケーションを実装できます。この構造は、有名なエンティティの概念を生み出しました。その結果、Drupal は、エンティティ クエリなどのデータに対するより多くの操作も提供し、ユーザーは Out を実装しますDrupal はそのままで包括的であり、ユーザーは独自のデータ構造を定義できます。

ThinkPHP はデータ層をサポートできません。ThinkPHP はモデルを使用してデータのカプセル化と操作を処理します。エンティティと比較すると、モデルは非常に初期の新しい概念です。モデルが実行できるすべてのエンティティを使用できます。ただし、その逆はありません。たとえば、このモデルは、入力用のフィールド コントロール、出力用のフォーマッタ、フォームやビューの表示コントロールなどをサポートしていません。その理由は、これらには高レベルの実装が必要であるためです。

中国と外国のオープンソースの生態とつながり:

完全に比較すると、Drupal も ThinkPHP でできることと同じことができることがわかります。 Drupal は、WEB オペレーティング システムとして知られる完全なバックエンド システムであるため、より多くのことを行うのに役立ちました。一般的なニーズは基本的にすべて利用可能であり、使用できます。 ThinkPHP 開発者は、これらの機能を取得するには、ThinkPHP に基づいて長い道のりを歩む必要があります。品質の問題は別として、時間の消費だけでも驚くべき数字です (たとえば、Drupal 8 の正式バージョンが登場する前)がリリースされ、そのさまざまな開発バージョンは 1,000 で構成されていました (多くの国際的なトップ開発者が 5 年間これに取り組んできました) 実際、多くの Drupal 開発者は ThinkPHP やその他のフレームワークを学ぼうとはしませんが、非常に奇妙な現象が発生する可能性があります。中国で見つけた: なぜ中国にはまだ中小企業がたくさんあるのでしょうか? ThinkPHP を使用していますか? (さまざまな採用プラットフォームで PHP 採用情報を検索すると、これについて少し理解できます。) これを説明するには 2 つの理由があります:

文化交流がブロックされている:

中国と外国の間の文化や生活の交流は依然として少数の人々に限られています。ほとんどの人には外国人の友人がいません。主な理由は、よく知られているネットワークの壁と言語の問題です。言語「障壁が主な理由であるはずです。我が国は急速に発展しすぎています。現在、国内の開発者の主力は70年代から90年代生まれのグループです。彼らのほとんどは英語でのコミュニケーション能力が低く、英語が話せません。彼らは本能的に英語の資料にアクセスしないことがよくあります 00 年または 10 年以降に生まれた人々 英語のレベルははるかに高いです (初期の教授やインターネットなどのおかげで) 将来的には、彼らはより社会に統合されるでしょう幸いなことに、現在ではテクノロジーが発展し、翻訳ソフトウェアのレベルはますます高くなっており、テクノロジーに熱中する人が増えています。上記を紹介すると、例えば中国の Drupal には、 「Drupal China」、「Aima Document Collection」、「Shui Drop Room」、「Drupal University」、「Think in Drupal」、「Ninghao.com」など。これらのプラットフォームまたはブログは、言語を排除した、膨大でほぼ完全な中国語ドキュメントを提供します。障壁。北京、上海、広州、成都、南寧、寧波などの都市にはDrupalをコア技術とする開発会社がある。

ストレスによって引き起こされるファストフード現象:

中国人は間違いなく世界で最も勤勉な国民の一つです。この勤勉さはプレッシャーと大きく関係しています。住宅、結婚、医療、教育、老人介護はそれぞれ大きな山です。」 「重要なことは、ほとんどの庶民にとって、創意工夫と長期的な蓄積を維持することはリスクが大きすぎ、安全性が欠如しています。今稼げるお金を最初に稼ぐべきです。何が起こるかは誰にも分かりません」社会が急速に発展する未来にこの現象は起こるのか? この現象は社会に悪影響を及ぼす 我が国の基礎科学分野へのダメージは甚大であり、急速に発展するIT産業においても同様である 開発者の負担が重すぎる. 996 は大企業からも尊敬されています。彼らは CURD のような単純なコード ファーマーの仕事を長い間行っています。多くの開発者は勉強する時間がまったくありません。家族、子供たちと時間を費やさなければなりません。 「休む時間がほとんどないので、深く勉強するのはさらに難しいです。時間に余裕があれば、プライベートの仕事をしたり、お金を稼いだりすることが多いです。このような一般的な環境では、誰もが慣れています」 「ファストフードを食べる」。鍬を持っていれば、まずそれを使う。彼らには掘削機を学ぶ時間がない。掘削機の開発にはさらに費用がかかる。結局、それが我が国のオープンソース産業の発展を困難にする。少数のオープンソース プロジェクトは商業的な色彩が強く、小規模企業は広告補助金やオープンソース プロジェクトに依存して商業プロジェクトを誘致して収益を上げます (ThinkPHP のホームページを見ればそれがわかります)。一方、大企業はそれを利用して収益を上げています。才能を確保し、無料でバグを除去するなど、オープンソースの選択には「影響力の範囲」の色が強い。一般に、純粋な愛と興味が占める割合は小さいが、これを中国の開発者のせいにするべきではない。プレッシャーのかかる環境のため、現在、一級都市から逃げる現象も起きていますが、混雑が少なく、時間に余裕がある二級都市に多くの人々が行きます。おそらく、彼らはオープンソースへの推進力となっているでしょう。アプリを入手(Luoji Thinking) はまた、中国のイノベーションセンターが余暇のある二級都市に移転する可能性があると予測しています。

それどころか、国際的なオープンソースの土壌ははるかに優れており、多くの先進国によって支配されており、これらの国は通常福祉国家であるため、圧力に比べて人々が努力する余地はあまりありません。自分の興味に基づいて物事を行う。オープンソースには多くの人が参加する。第一に考えられるのは人生の意味である。これについては「マズローの欲求モデル」がある。読者はそれを学ぶことができる。「いいね!」は「品質」を保証し、メリットがある毎年開催される DrupalCon カンファレンスでは、インターネット上で、多くの開発者が非常に高齢であり、その多くは 50 代、60 代であることがわかりますが、彼らは明るい目でテクノロジーについて語り、生涯の蓄積を Drupal に注ぎ込んでいます。

もちろん、国際的なオープンソースには先進国が主に参加しているわけではなく、英語圏の後進国も主要な参加国であり、オープンソースから派生した商業プロジェクトを通じて外貨を稼いでいる場合が多いです。真剣に言うと、インドはかつてイギリスの植民地であり、富裕層の間での英語の人気が非常に高いため、インドは国際的なオープンソースに高度に統合され、それに応じてインドの比較的高いソフトウェア開発力が生み出されました。

開発者のキャリア プランニング:

このセクションでは、国内開発者のキャリア プランニングの問題について説明します。国内社会では常に次のような声がありました。 「プログラマは若者の食べ物」と言われ、これは通常35歳の基準に相当します。某大手企業では35歳の開発者を解雇しているのをよく見かけます。企業によっては採用年齢制限を35歳以下にしているところもあります。 35歳というのは不思議 より深い能力を蓄積し、多くのことを適切に処理できる年齢ですが、なぜこのような現象が起こるのでしょうか?見てみましょう:

まず、これらのニュースは、「女性ドライバー」と同様に、注目を集めている疑いが非常に高いです。実際、女性ドライバーの事故率は男性ドライバーよりも低いのです。ニュースだけで閲覧できるのですが、このようなニュースが多すぎると錯覚してしまうので、35歳という閾値はある程度誇張されすぎていて、悪影響があり、理由もなくトレンドに従う人さえいます。

しかし、35 歳のしきい値にはある程度の真実があります。これは選択的に区別する必要があります。開発者が CURD (実際のコーダー) のような単純で反復的な物理的な作業を行っている場合、彼が 35 歳のしきい値に達したとき、 35歳という年齢は、学校を卒業して1~2年経ったばかりの若者と比べると競争力が増してくるのが想像できますが、35歳という年齢になると、子供たちには学校に行くこと、親の健康、住居などの条件により、開発者はより高い給与の要求、家族の事情、社交性などを提示する必要があります。また、長時間待たなければならず、残業はしたくないのです。通常、長期間勤務した場合の累積給与は相対的に高くなります。若い人があなたの仕事と同じことができるとしたら、上司は誰を選ぶでしょうか?上司が自分よりずっと若い男性の場合、従うべきでしょうか?若い人にとって、自分よりずっと年上の人を管理するのは気まずいこともあります。これらを踏まえると、35歳という閾値の存在には一定の理由があることが分かります。

時間は誰も待ってくれません。開発者はどのようにして 35 歳という年齢を回避し、どのように人生計画を立てるべきでしょうか?

自分がテクノロジーがあまり好きではないとわかったら、その年齢でまだ競争力があるうちにできるだけ早く変革し、自分の心に従って、好きなことを見つけて競争力を蓄積し始めるべきです。

本当にテクノロジーが好きで、それに人生を費やす覚悟があるなら、効率的に蓄積し、学び続け、プレッシャーや体力の少ない若者との技術差を広げることに常に注意を払う必要があります。 「強いアドバンテージがあるなら、それを技術的なアドバンテージで補う必要がある。名人への道は、選択できるかどうかではなく、必ず必要なものである。35歳になったら、名人にならなければならない」偉大なマスターであり、若い人には難しいシステム上のポジションを引き受けます。

注意していただきたいのですが、社会の発展に伴いテクノロジーの敷居は実は徐々に上がってきており、例えば「フルスタックエンジニア」という言葉を聞いたことがあるかもしれませんが、それはまだ黎明期の話です。インターネット時代、社会の分業が進みすぎている今、あまりにも細かい部分が深すぎると全体の積み重ねが存在しなくなり、もし存在したとしても「全部知っているけどスキルに差がある」ということになってしまいます。人々のエネルギーの差があまり大きくないからです。あなたはすべてを学ぶことを選択しますが、他の人は 1 つの分野を学ぶことを選択します。雇用主は立場に基づいて人を採用します。どちらが有利かを考慮する必要があります。理由が選択を促します。一つのテーマを深く掘り下げて周囲の領域を理解することですが、そうすると自分は大きな機械の一部となり選択の自由が制限され、細分化の閾値の要件も非常に厳しくなり、熟練を追求しなければ、淘汰されることになるでしょう。

このような機械部品を作るのは起業家志望の人には向いていないので、起業するときに何が直面するのでしょうか?中国社会の発展を見ると、Web サイトがパブリックアカウントに置き換わったり、小規模な Web サイト市場も SaaS プラットフォームに占有されたりするなど、一般的な IT ニーズをすべて満たすことができなくなっている可能性があります。マウスをクリックするだけで初期化でき、コードを記述する必要があり、時間ベースの料金は非常に低額になる可能性があります。1 回限りの料金を請求する必要があります。顧客の観点から見ると、最初に考慮するのは当然のことながらコストです一般的な要件には、電子商取引システム、ライブブロードキャストシステム、コンテンツ支払いシステムなども含まれており、これらはすべて非常に成熟した既存のソリューションを備えており、スケールメリットの点では、Weimeng、Youzan、Weiqing、Weijianmuなどはすべて非常に優れています。優れた SaaS プラットフォームが開発されていますが、一般以外の IT ニーズについてはどうですか?美団、滴迪、トゥバツ、ディングアグアなど、多くの垂直フィールドで解決策が形成され、山の頂上が占領されて分割されます。彼らのフィールドでチャンスを得るのは難しく、数だけが残ります。 「本当にカスタマイズが必要な要望はそれほど多くない。この種の要望には一つの特徴がある。カスタマイズなので、コスト上の理由から単価が高くなければならない。このとき、顧客は、その強度に対する要求を持っている」起業家の会社です。従業員は何名いますか?オフィスの広さはどのくらいですか?歴史の蓄積はどれくらいですか?ケースは何件ありますか?登録資本金はいくらですか?

さらに、今日の IT の発展に伴い、同じアプリケーション システムでもソフトウェアの観点からはさまざまな形式が取られ、通常は 1 つ以上のアプリ、小さなプログラム、Web ページなどが必要になります。クロスプラットフォームが含まれます (APP には Android、IOS、今後登場する Honmeng があり、ミニ プログラムには WeChat、Alipay、Baidu、Douyin などが含まれます)。UNIAPP のようなツールもありますが、顧客がネイティブ アプリケーションを必要とする場合には、依然として多くのスキルが必要です。チームメンバーには営業マンや財務担当者など技術者以外の人材も含まれており、これらが一定の参入障壁となっています。しかし資本も。

そうは言っても、道は険しいと感じませんか?しかし、これはIT分野に限ったことではなく、競争の場でも同じだと信じて、簡単に成功することはありません。自分の興味だけがどこまで高くなれるかを保証しますので、自分の心に従ってください。

自分の心に従って、慎重に検討した結果、それでもテクノロジーを選択し、偉大なマスターになることを選択した場合、何をすべきでしょうか?まず第一に、蓄積に重点を置く必要があり、特に巨人の肩の上に立って未開発の土地に向かって突進する必要があります。自分のニッチで最も有望なエコシステムを見つけて参加し、PHP 開発フレームワークである小白に戻る必要があります。フレームワークは、必要な機能をさらにカプセル化して提供するだけですが、専門家は、このフレームワークは統一されたコラボレーション プラットフォームを提供すると考えています。全員が同じプラットフォーム上で作成するため、車輪の再発明を避けることができ、経済的コストの観点からは十分です。費用対効果が高く、みんなの力を借りて、手を解放して独自のビジネスを発展させることができます。

基本プラットフォームの統一性は非常に重要です。そうすることでのみ、人間は蓄積し、前進し、コストを削減することができます。しかし、統一されたプラットフォームの形成には興味深い法則があります。 1 つはメイン プラットフォームとして残され、次に別のプラットフォームが存在します。2 位のプラットフォームは競争力のある予備を形成するために使用され、3 位と 4 位のプラットフォームは基本的に無視できます。1 位と 2 位は大きく異なります。サイズの点で言えば、そのような例は歴史上たくさんあります。オペレーティング システムは何千もあり、最終的に残るのは Windows と Linux だけです。この 2 つのユーザーの数には大きな違いがあります。同じことが当てはまります。 Android と Apple、淘宝と JD.com、Douyin と Kuaishou、Meituan と Ele.me など、一度形成されたパターンを揺るがすのは困難です。たとえば、Microsoft が Android を揺るがせないのはテクノロジーのせいではありませんが、雪だるま効果が働いているからです 王はより強く大きくなり、敗者は徐々に孤独になって消えていきます たとえ王が小さな失敗をして成長したとしても それは変えることができません 例えば私たちが今使っているキーボードは最も合理的な文字配列を持っていない 歴史上、合理的な配列のキーボードはありましたが、誰もが現在のキーボードに慣れているため、それを使い続けます 王様になるために重要な点は 2 つあります。群集生態学は雪だるま式効果を確立する必要があり、これら 2 つの点は相互に補完します。

それでは、PHP フレームワークの分野におけるこの統一された基本プラットフォームになるのは誰でしょうか?オープンソース プロジェクトの主な開発力は、少数の人々が自分の考えや経験に依存するのではなく、多数のユーザーが使用中に改良と要約を続け、その後一緒に議論し改善し続けることであるべきです。 ThinkPHP と Symfony Make のどちらかを選択する場合、答えは非常に明白です。実際、Symfony は統合プラットフォームの重要性を非常に早くから認識していたので、分離された完全な基本コンポーネントの確立に専念し、繰り返し反復してきました。 Laravel や ThinkPHP など、他の既存のフレームワークも Symfony コンポーネントを使用しているため、Symfony は繰り返し「標準」を強調しており、標準化は統一プラットフォームの必要条件であるため、現在では PHP 開発の分野で事実上の標準となっています。

Drupal は、完全なシステムの標準基盤となっている Symfony をベースに構築された上位の統一標準プラットフォームであり、一般的に使用されるアプリケーション層の機能はほぼすべてここで提供されています。モジュール設計に基づいた統一プラットフォーム上で、Drupal の理想である「優れたデジタル体験の提供」を実現するために、より未来志向の機能が生み出されます。

意思決定者のテクノロジ選択:

あなたが起業家精神にあふれた上司またはプロジェクト ディレクターで、プロジェクトのテクノロジの選択を行っている場合は、次のとおりです。注意すべき点がいくつかあります:

コストの管理:

言うまでもなく当たり前のことですが、本当に管理できていますか?ソフトウェアは目に見えないものです。専門家でない場合、コストを管理するのは困難です。ここにいくつかの落とし穴があります:

現在の環境では、長期計画プロジェクトを実行したい場合、それを自分で開発できます。いくつかのものをアウトソーシングしないでください。同じように見えますが、実際には大きな違いがあります。専門家でない人には、堅牢性、拡張性、セキュリティ、持続可能性などの点で 2 つのシステムの違いを理解するのは困難です。たとえば、 「同じ機能のシステムの負荷が5,000の場合と、負荷が5,000の場合では、数千万の開発コストは全く異なります。例えば、ソフトウェアのドキュメント作成の作業負荷は、ソフトウェア開発そのものよりもはるかに高い場合があります。ドキュメント化は、システムの長期開発を保証する鍵ですが、アウトソーシングでは完全な文書化を達成するのが困難です。アウトソーシングの品質により、通常は非効率になります。将来料金を支払う理由は、アウトソーシング会社が強くないからではありません。 、しかしコストがかかるため。

技術的負債の削減:

最初のコストを節約するためだけに十分な経験を持たない開発者を見つけないでください。ここでストーリーを共有しましょう。上司とテクニカルディレクターです 人材採用には差がありました テクニカルディレクターは給料15,000を要求しました 応募者が来ましたが8,000しか希望しませんでした テクニカルディレクターは望んでいませんでしたが、上司は大喜びで考えました彼は利益を得ていたのに、なぜ愚かにももっと金を払わなければならないのでしょうか?時々、初心者はシステムに大きな隠れた危険を残すことがあります。このテクニカルディレクターは、技術的負債の問題を認識していました。開発チームは、システムを制御するための深い技術的バックボーンを持っていなければなりません。同時に、基本的なシステムを選択するときは、選択しないでくださいこうすることで、技術的負債をできる限り負わないようにすることができます。そうしないと、その道に慣れ始めて、後で泥沼にはまってしまいます。重要なビジネスウィンドウ期間に遭遇した場合でも、神はあなたを救うことはできません

加速するための活用:

今日の社会の発展に伴い、多くの IT システム機能がすでに存在し、非常に完成されています。 「自分で開発する必要はありません。例えば、ThinkPHP か Drupal のどちらかを選択しなければならない場合、私は迷わず Drupal を選択します。ThinkPHP は単なる半完成品であり、通常、さまざまな業務システムで必要な機能があるためです。ガベージコレクションシステム、ステータスシステム、キーバリューストレージ、バッチ処理システム、スケジュールされたタスクシステム、データタイピングシステム、Ajaxシステム、データ表示エンジン、バージョンサポートシステム、パーミッションシステムなどはThinkPHPでは利用できませんが、Drupalは非常に便利です。これらを ThinkPHP で開発するには数か月から数年かかります。基本的な統合プラットフォームの利点がないだけでなく、自分で開発したコードの品質を確保することも困難です。リソースが無駄になるだけでなく、また、新規メンバーは後の段階で高額なトレーニング費用を支払う必要があるため、完全な基盤を備えた既製の成熟したシステムを使用してはいかがでしょうか。

環境への統合:

開発システムは一般的な環境に統合される必要があります。高速化の活用に加えて、開発者をプロジェクトから切り離すために予備の人材を獲得することにも依存します。既存の開発者が退職したり、退職したりしたときに十分な開発者を見つけることができないということがないようにする必要があります。プロジェクトに迅速に参加し、より大規模な環境に統合し、開発者を分離することで、プロジェクトの開発セキュリティが大幅に確保されます。

国家オープンソースの推奨事項:

#このセクションでは、オープンソースがどのように扱われるべきかを国家レベルで検討します。 「中国はますます強くなっている。中国人は中国が米国を超える日を心待ちにしている。中国が米国の封鎖を突破し、超えるという目標を達成したいなら、国際オープンソースに参加し、主要な貢献者にならなければならない」 、独自の独立したシステムを構築するのではなく(新しい時代には自己構築システムが発生するはずです。次世代のモノのインターネットオペレーティングシステムHongmengなどの点では)、オープンソースはすべての人にとってオープンソースであるため、 「どの国のためでもなく、人類のためです。密室で働き、外出するのは賢明ではありません。そうすれば中国は世界から遠ざかることになります。中国の人口はわずか 14 億人であり、世界には 70 億人以上の人々がいるということを知っておく必要があります」したがって、オープンソースに参加し、貢献に努めるのが合理的であり、第一に、これまでの人類開発の成果を継承し、巨人の基盤に基づいてより迅速に開発することです。大多数の人々とともにいることを選択し、国への扉を開き、影響力を確立して初めて、偉大な国のイメージを確立することができます。

[関連チュートリアルの推奨事項: thinkphp フレームワーク]

以上がDrupal と thinkphp を比較して国内のオープンソース環境を確認の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。

声明:
この記事はdrupalchinaで複製されています。侵害がある場合は、admin@php.cn までご連絡ください。