こんにちは！ 確かに多くの人が、Bitrix CMSが何であるか、それが何であるか、そしてその「素晴らしい」コードとその開発者が表すアーキテクチャソリューションを知っています。 この投稿では、システムコンポーネントとモジュールの開発に関する新しいビジョンを提供したいと思います。
Hmvc
これらの4文字が何であるかを説明する前に、最後の3文字の意味を思い出させてください。
MVC自体は、システムを3つの部分に分割する設計パターンです。
- モデル -ビジネスロジック。
- コントローラー -制御/相互作用ロジック。
- プレゼンテーション -UI。
このテンプレートの利点は、通常実装される場合、ビジネスロジックがCおよびVから完全に独立していることです。 誰が詳細を必要とし、何らかの理由で誰がまだそれが何であるかを知らない-google先に進む。
MVCはほとんど万能薬（すべての問題を解決するようなもの）ですが、システムが十分に大きい場合、必然的により複雑になり、その結果（または原因）スケーリングの問題が発生します。 良い友達が助けに来ます： H-Hierarchical 。
このテンプレートの主なアイデアは、システム全体が個別の独立したトライアド（MVC）に分割され、コントローラーを介して互いに通信することです。 したがって、ビジネスロジックは依然として外の世界から隔離されており、実際、システムは自発的に小さな部分に分割されます。これは、大規模なシステムで必然的に生じるスパゲッティ依存よりもはるかに便利で単純です。
トライアドの通信は、コントローラーへのリクエストを通じて行われます。 次の種類のクエリを区別できます。
- 外部リクエスト -別のサーバーへのリクエストの作成（神の配布）;
- 内部リクエスト -現在のサーバーへのリクエストを作成します。
- 関数呼び出し -サーバーへの追加リクエストなしで、コードからコントローラーアクションを呼び出すだけです。
Bitrixと彼のゴキブリ
Bitrixは、非常に公表された非常に使いにくい開発者管理システムです。 しかし、実際にはこれはそれについてではないので、ビジネスに取り掛かりましょう。
著者によると、このシステムはMVCパターンを実装しています。 次のようになります。
ええと...真剣に？ モデルは、コントローラーやビューとは別に、システムの別の構造部分に配置されます。 別に、カール!!!
実際、これはかなり成功した動きです。なぜなら、 システム全体はコンポーネントに基づいており、それぞれが任意のモデル、任意のモジュール、正確には特定のモデル、つまり情報ブロックを引き出すことができます。 しかし、MVCの観点から見ると、これは真実ではありません。コントローラーはロジックでオーバーロードされています（少なくとも標準コンポーネントの実装を見ると）。
ビトリックス。 モデル
インフォブロックは、情報を保存するための非常に便利で柔軟なソリューションです。議論することはできず、このツールを無視するのは愚かなことです。 明確にするために、一般的な場合のシステムの構造は次のように表すことができます。
この写真を見ると、モデルを分離するという決定は素晴らしいと結論付けることができます。 ただし、この場合、コントローラー（コンポーネント）には多くのロジックがあり、モデル（API）は単なるドメインモデルであり、ロジックは含まれていません。
ビトリックス。 コントローラー
Bitrixは、コンポーネントがコントローラーとして機能することを保証しますが、これには同意しません。
コンポーネントはウィジェットです。入力としてデータを受け取り、何らかの方法で変換します。
複雑なコンポーネントはコントローラー（より正確には、フロントコントローラー）です。ユーザーの要求を入力として受け入れ、それを解析し、要求されたアクションを開始します。 概略的には、これは次のように表現できます。
ビトリックス。 Hmvc
MVCに関するBitrixのプレゼンテーションで会いました。次に、コントローラー（コンポーネント）間の通信のオプションを検討します。
ドキュメントが私たちにアドバイスしているように：コンポーネントはグローバル変数またはイベントを通して通信できます。 実際、これらはモジュール間の連携に関するヒントですが、厳密に言えばコンポーネントについては、適用可能でもありますが、完全には適合しません。
- グローバル変数 -暗黙的なデータ転送。
- イベント -通常、興行を過ぎた。
だから、私の意見では、パラメーターを参照渡しするのが最適です：
<? $APPLICATION->IncludeComponent('comp1','',[& $params]); $APPLICATION->IncludeComponent('comp2','',[$params]); // $APPLICATION->IncludeComponent('comp1','',['request' => $req, 'response' => & $res]); $APPLICATION->IncludeComponent('comp2','',[$res]); ?>
すべてが透明で、どこで、何で、いつ到着するかが明確です。
それはすべてのようですが、いいえ。 個別のコンポーネント（複雑ではない）は、個別のMVCトライアドである必要がありますが、厳密にはそうではありません。 サービス層が助けになります：
この構造のおかげで、各コンポーネント（複雑ではない）には、データベースを操作するためのAPI（ドメインモデル）を順番に参照する必要なビジネスロジックを持つ独自のモデル（サービスレイヤー）があります。
少しのせん妄
もちろん、上記の段落で記事を終了することは可能ですが、感情が引き裂かれているので、私は沈黙することはできません。 プロのレベルに関係なく、すべてのbitrixoidsが1つの声で叫ぶという事実に非常に驚いています。「箱から出していない場合は、すべてを使用します。 問題は、「なぜ市場なのか？」、しかしまあまあです。
みんな、本当に？ あなたは開発者ですか？ 私はBitrixがMUCHがあるコンストラクター（意見があると思う）であると理解していますが、もう1つ：たくさん-これはすべてではありません 。 そして、Bitrixoidsが標準モジュールを使用し、それらに基づいて何かを行うと言うと、非常に悲しくなります。
私はすべてのモジュールを書き直して、たくさんの自転車を彫刻することを勧めません（ただし、市場にはたくさんあります）。 もちろん、スキルを向上させるためには、いくつかのバイクを書く価値がありますが、APIのみを標準モジュールから取得することができます。