私たちは皆、既存の人気のあるPHPエンジンをよく知っています。 また、アマチュアによって開発された誰にもほとんど知られていないことに言及することができます。 しかし、それらはすべて、アイデアの点で1つの大きな「BUT」によって結ばれています。 負荷の高いプロジェクトを開発するときに誰もCMSを使用しないのはなぜですか？ 問題は、個々の状況は言うまでもなく、それぞれが非特定機能の開発をあらゆる方法で妨げるように設計されていることです。
このアイデアは、私がプログラミングを始めたときに思いつきました。 それ以来、何年もが経ち、多くの経験が積まれ、実践されました。 一般に、比較するものがあります。 私にとってほぼ完璧な例は、PythonのDjangoです。 しかし、エンドユーザーは、インターフェイス、基本機能などを磨くのに多くの時間を必要とします。 そして、私は、システムのカーネルなどを書くことは、私の開発に有利な建設的な批判を最大限に提供する公衆の厳しい指導の下で行う方が良いと思いませんでしたか？
基本的なプログラミングパターン
私の経験では、最も一般的なプログラミングパターンは現在MVCとその修正です。 私は何度もパターンに従って書き込もうとしましたが、その結果はいつも私を夢中にさせました。 すべてをModel-View-Controllerに分割して分割することはできません。 もちろん、私は間違っている可能性があり、それがあなたがこれを読んでいる理由です。
例として、APIを使用した簡単な作業と、Userなどのモデルデータとの同期を考えてみましょう。 エンジンの場合、フレームワーク（誰にとっても便利です）-Symfony。 確かに、この問題の経験豊富な人々は、それがすべて始まり、どのように終わるかをすでに理解しています。
私の選択肢は理想とは言えませんが、本当に気に入っています。 これの本質は、システムデータ、計算されたデータ、他のサービスのデータを使用した操作はすべてServiceとして配置されることです。 このサービスは基本的に、クラスと独自の名前空間を持つ通常のPHPパッケージです。 しかし、構成ファイル、Viewパーツの基本テンプレート、またはキャッシュされたデータをそこに配置することを誰が妨げていますか？ 結局のところ、これらすべては特に彼に関連しているので、テンプレート/構成用の共有フォルダーを詰まらせる必要がありますか？
- サービスのみがデータベースにアクセスできます
- サービスには、クラス、特性、構成およびキャッシュファイル、基本的なテンプレートが含まれる場合があります
- サービスへのアクセスは、コントローラー領域から単一のオブジェクトメソッドを使用して実行されます。
- サービスには独自の名前空間が必要です
このソリューションにより、システム全体の変調が大幅に簡素化されます。 コントローラーがデータベースにまったくアクセスできない場合、必要なデータを取得するために、たとえばサービスの特性を編集する必要があります。 しかし一方で、コードを正しく整理し、互いに干渉しないようにするのに役立ちます。
注意深く考えれば、これは同じMVCであり、ここでのみ、モデルの役割がサービスによって果たされます。
その結果、Userサービスのファサードクラスには、ローカルデータの処理、サーバー上の独自のファイル、APIの処理などを含めることができます。 このような大きな開発分野の統一により、最終結果を非常に効率的に実装することが可能になります。
私はあなたの意見を本当に知りたいです。