私は PHP 開発者であり、Java EE テクノロジについて読んでおり、そのようなテクノロジ (n 層、EJB、JPA...) を PHP とすべてのもの (MySQL、Apache...) で実装したいと考えています。
2 に答える
しないでください。
PHP は Java ではありません。Java コードを書くように PHP コードを書くのはばかげており、非生産的です。コードの将来のメンテナーがあなたを傷つけたくなる可能性が非常に高いです。
オブジェクトを永続化する必要がありますか? ORM を使用します。
多層アーキテクチャが必要ですか? 関心を適切に分離してコードを設計すれば、すでに 9/10 の成果が得られています。
EJB?ウィキペディアの記事を読むたびに、それらは異なって説明されています。再利用可能なコンポーネント? 何のための標準化されたインターフェース、分散アプリケーション、およびデータ永続性を備えていますか? 便利ですが、それは PHP ではありません。ORM と適切なメッセージ/作業キューがあれば、仕事は完了します。
結論:大部分の PHP スクリプトでは、「エンタープライズ テクノロジ」は必要ありません。 もしそうなら、あなたは何か間違ったことをしています: アプリケーションをオーバーアーキテクチャにしたか、間違ったプラットフォームを選択したかのどちらかです。
最新の PHP フレームワークを選択することから始めて、そこからアプリケーションを構築します。Java を使用している場合、Zend Framework は最もなじみがないと思われるでしょう。Kohana、Symfony、CodeIgniter はすべて価値があります。今のところケーキは避けてください。
シンプルにしておけば間違いはありません。
あなたの質問は洞察に満ちたものです。これは、企業が成功するにつれて、より多くのトラフィックの負荷をサポートするためにスケールアップする必要があるためです。そのため、PHPコードを、別々の層(別々のサーバー、またはXenのように別々の仮想マシン)で実行されるレイヤーに分割する必要があります。
たとえば、昨年、約25台のXen仮想マシン(VM)を実行する10台のLinux OpenSUSEサーバーにPHPで実装されたシステムを設計しました。VMの一部はロードバランサー、一部はフロントエンド層、一部は中間層、一部はバックです。エンドティアには、MySQLデータベースが含まれているものもあり、ユーザーファイルストレージ用のRAIDアレイである専用サーバーがいくつかありました。RAIDアレイとの間でファイルを保存/読み取るために、必要に応じてNFSマウントを作成しました。
ティアを3つの関連グループにグループ化したため、QA、ステージング(ユーザー受け入れ)、および本番用の独立したテストサイトを作成できました。
そのため、PHPソフトウェアは、次のように緩く結合されたレイヤーに分割されました。
フロントエンドティア(VM)
- アプリケーション層(ポート80)-AJAX応答、検証コード、ナビゲーションなどを含みます。
- 管理レイヤー(ポート443)-システムメトリックとユニットテストハーネスにアクセスできる管理ダッシュボードを含む
- サービスプロバイダー(ポート443)-システムを「プラットフォーム」として使用するパートナーやその他のユーザーにサービスを提供するための安全なRESTful WebサービスAPI(トークン付き)。
ミドルティア(VM)
- ビジネスロジックレイヤー-システムまたはビジネスに固有の計算、またはさまざまなユースケースの役割と権限
- 相互運用性レイヤー-ソーシャルネットワークやパートナーアプリケーションなどへの承認と投稿。
バックエンド層(VM)
- データアクセス層-データベースが別の種類に変更されたときに適応できる方法で、SQLクエリ、挿入、更新、データベースへの削除(プリペアドステートメントとして実装)を処理します...例:PostgreSQLからMySQL、またはその逆。データベースをバックアップおよび復元するためのPHPコードが含まれています。
別の回答者がエンタープライズソフトウェア用のフレームワークを使用することについて提起したアイデアは、私にはかなりばかげているように思えます。学生プロジェクトまたは「概念実証」を単一のサーバーで開発していて、すでにフレームワークに精通している場合は、ラピッドプロトタイピングに使用できる可能性があります。
しかし、上記からわかるように、複数の層に分散された本番品質のコードを作成する場合、フレームワークを使用するという松葉杖は必要ありません。
コード内のすべての場所にリンクするフレームワークをどこに配置しますか?すべての層で?悪いアイデア。フレームワークには、必要な場合と不要な場合がある多くのページが含まれています。そのため、特にインストールする必要のあるすべての層を掛けると、パフォーマンスが低下します。
同様に非効率的なのは、他のすべてのレイヤーが呼び出さなければならないフレームワークを含めるためだけに「レイヤー」を作成することです。ソフトウェアレイヤーの利点は、緩く結合され、他のレイヤーから独立しているため、あるレイヤーで変更が発生した場合に、別のレイヤーで変更を行う必要がないことです。
さらに、本番品質のコードを作成する開発者は、フレームワークが表す「スイスアーミーナイフ」に依存する必要はありません。このような開発者は、対象を絞った効率的なコードを記述でき、必要に応じて、以前のプロジェクト用に開発した可能性のあるライブラリ内のクラスを再利用できます。