カプセル化クラスを使用して PHP プロジェクトを合理的に設計する -- PHP プロジェクトにおけるクラスのカプセル化について説明する

パッケージング|デザイン|プロジェクト

資格のある PHP プログラマーにとってコーディングは難しくありません (おそらく、どれだけ時間がかかるかの問題かもしれません)。そのため、システムの分析と設計の段階が特に重要です。ただし、この記事は需要分析やビジネス ロジックの取得に関連するトピックを説明することを意図したものではなく、システム設計について説明することを目的としています。
困難に直面する
資格のある PHP プログラマーにとってコーディングは難しくありません (おそらく、必要な時間の長さの問題かもしれません)。そのため、システム分析と設計のこの段階は特に重要です。 PHP プロジェクトに取り組んでいるシステム アナリストは 2 つの問題に直面しています:

PHP 言語自体の制限。
これは、複雑なシステムのオブジェクト指向設計で特に顕著です。 PHP のオブジェクト指向機能は現在のバージョンで改善されていますが、まだ完全ではなく、長期的な観点から見ても、新しい PHP はオブジェクト指向設計の実装言語として機能するには十分ではありません。 Zend Engine 2.0 は間もなくリリースされますが、オブジェクト指向の機能は、一般的な Java や C++ の機能とは異なります (この点については、developerWorks China Web サイトで公開した別の記事を参照してください)。しかし、完全にプロセス指向（正確にはWebページ指向）のアプローチを採用すると、システム全体の設計が非常に複雑になり、コーディングの複雑さや保守の困難さがさらに困難になることが考えられます。対処するために。
既存の情報が大幅に不足しています。
Web プロジェクトのシステム設計情報が不足していることはよく知られていますが、その限られた情報の中でも、PHP に関する設計情報は非常に不足しています。会社または私に関連する技術的蓄積がない場合、システム アナリストは暗闇の中でメソッドを探索することしかできません (2 つの最悪の状況は、1 つは Java や C++ などの他のプロジェクトの設計をコピーすること、もう 1 つは次のように考えることです)プロジェクトは単純であり、責任は軽視されています。）



直面しているシステムを理解してください
この場合、PHP システムの分析と設計を適切に処理するにはどのような方法を使用する必要がありますか?最初のコンセプトでは、プロジェクトによって実行されるタスクの種類を区別する必要があります。

オフィス システム、注文システム、その他のビジネス システムなど、顧客自体または顧客の業界の多数のビジネス ロジックが関与するプロジェクト。
ブランド Web サイトやイベント Web サイト、その他の Web サイトなど、高トラフィックに耐える必要があるプロジェクトや迅速な対応が必要なプロジェクトを含む、単純な Web サイト プロジェクト。
総合的なウェブサイトプロジェクト。通常、ニュース サブシステム、フォーラム サブシステム、製品表示サブシステムなど、比較的独立した複数のサブシステムが含まれています。



PHP は元々、後者の 2 つのプロジェクトの緊急のニーズを解決するために設計されており、言語自体はこれらのプロジェクトのために適切に変換されています。多くの PHP 開発者も多かれ少なかれこれらのプロジェクトの経験があり、関連書籍の例のほとんどはこれを中心に展開しています。比較的、最初のシステムに関する情報は少なく、さまざまな出版物でもその内容について言及されることはほとんどありません。したがって、この記事では、タイトルで 1 番目のタイプのプロジェクト (MVC パターンとクラスのカプセル化について) について詳しく説明し、2 番目のタイプのプロジェクト (ハッカー コードについて) と 3 番目のプロジェクトの設計方法についても触れます。もちろん、分類されたプロジェクトがこの記事で説明した方法のみを使用できるというわけではありません。システム アナリストは、選択を行う前にさまざまな要素を検討する必要があります。

オプション 1: 多数のビジネス ロジック プロジェクトが関与する
ユーザー インターフェイスとバックグラウンド操作をどのように分離するか?ビジネス ロジックと一般的なプロセス制御の混同を避けるにはどうすればよいでしょうか?本格的な商業プロジェクトとして、多くの同様の問題を考慮する必要があります。 PHP によってホストされるこのタイプのプロジェクトの場合、Model-View-Controller (MVC) パターン設計の実装は非常に良い方法です。

理論的説明
ここでは MVC パターン自体について説明するつもりはありません。単純に、システム設計を 3 つのロジック (モデル モデル/ロジック、ビュー ビュー/インターフェイス、およびコントローラー制御/) に分割することによって、リテラルとアプリケーションの観点から話します。プロセスが部分的に良好なプロジェクト結果を達成することで、各部門の開発者の作業が容易になり、将来のメンテナンスコストが削減されます。 (JSP 開発のモデル 2 パターンに精通している場合は、これが MVC パターンの優れた具体化でもあることがわかります。) 実際のプロジェクト開発に関する限り、既存の大きな問題には、作業の重複と競合が含まれます。 Web デザイナーとプログラム開発者の間で問題が発生し、ページにビジネス ロジックが埋め込まれているため、ページが再利用できなくなり、メンテナンスが困難になります。 MVC モデルの導入は、システム全体の設計に明確な方向性を示すことができる一方で、開発チームの分業の良い指針にもなります。

システムの全体構造はMVCモデルの要件に応じて論理的に3つの部分に分割されるため、チームの開発者の中には各部分の開発者も存在します。

開発者の役割 システム ロジック関連の責任
Web デザイナー ビュー/インターフェイス すべてのユーザー インターフェイスの Web テンプレートを設計します。
コントロール プロセス開発者 コントローラー コントロール/プロセスは、システム プロセス内のすべての PHP ページを書き込みます。
ビジネスロジック開発者 システム設計で指定された各種クラス(その中のメソッド)をモデルモデル/ロジックで開発します。



上の表からわかるように、Web デザイン担当者とプログラム開発担当者間の従来の分業体制は崩壊し、システム ロジックに従って詳細に定められた責任に置き換えられています。正確に言うと、Web デザイナーの責任は変わっていません。この部門では、これまでのようにプログラマーとの紛争が回避されます。そのため、純粋な Web コード (主に HTML、おそらくその他のクライアント) のみに集中する必要があります。 WML などのサイド コードは、サーバー側の によって干渉される必要はありません。プログラマは 2 つの部分に分かれています。理解しやすいのはビジネス ロジック開発者です。彼らの仕事は、システム アナリストによって与えられたモジュール (正確にはクラス メソッド) を完成させることです。彼らが扱う PHP は、一般的なプログラミング言語に似ています。 (Java など) は Web とは何の関係もありません。現時点で受け入れが難しいのは、システム設計時に策定されたシステム プロセスを実装しながら、クライアントの入力に基づいてビジネス ロジックを呼び出すことです。 (対応するクラス メソッド) と更新されたインターフェイスの出力 (Web ページ テンプレートのデザインの処理) を手に入れることで、PHP は Web プログラミング言語の利点を最大限に発揮することができます。

コード構成に関するトピック
この概念はやや抽象的であり、例のないデモンストレーションを受け入れるのは困難です。例を示す前に、このタイプのプロジェクトに推奨するコード構造を紹介します。

第 1 レベルのディレクトリ 第 2 レベルのディレクトリ 第 3 レベルのディレクトリ 備考
/project_name プロジェクトのソース コードのルート ディレクトリ
/Templates Web テンプレート ディレクトリ (表示)
/admin プラットフォーム ディレクトリ /admin にある管理コントロール Web ページ テンプレート
/Include ビジネス ロジック ディレクトリ (モデル)
/Temp 開発者がいくつかの実験コードをテストするための一時コード ディレクトリ (オプション)
/images 画像ディレクトリ、Web ページ テンプレートが使用
/css スタイル シート ディレクトリ、Web ページ テンプレートは
/scripts クライアント コード ディレクトリを使用、Web ページ テンプレートは
/admin 管理コンソール ディレクトリ (オプション) を使用、すべてのバックグラウンド管理関数コードを含む
/other_dir はソース コード ルートの /other_dir に対応directory には、このクラスを管理するための関数コードが含まれています
/other_dir ユーザーに関連する /member ディレクトリやスレーブ製品に関連する /product ディレクトリなど、対応する機能に関連するその他のディレクトリ
/config.inc.php グローバル設定変数、定義 システム内のグローバル変数
/security.inc.php セキュリティ ポリシー コントロール (オプション)
/error.php エラー コントロールのリターン ページ (オプション)、/error.html などの静的ページや他のページ名も使用できます



これを読んだ後、Web 開発に Java を使用することを思い出しましたか?たとえば、WEB-INF ディレクトリの下のクラス ディレクトリ、lib ディレクトリ、および web.xml はすべて開発ルールです。ただし、PHP をサポートする Web サーバーが Java アプリケーション サーバーのようにこれらのディレクトリにファイルを自動的にロードすることは不可能ですが、適切なコード編成モデルは、依然として開発とその後のメンテナンスの利便性を非常に高めています。 (私は PHP プロジェクトのコード構造について考え始め、Tomcat 開発マニュアルに触発されました。)

ユーザーログインの例
上記のコードディレクトリによれば、上記の MVC パターンの実装をより簡単に説明できます。 。最も一般的なユーザー ログイン関数を例に挙げると、/project_name ディレクトリの下に、ユーザーに関連するすべての関数を含む /member ディレクトリがあり、これには、ユーザーを受け入れるために login.php ページで使用されるユーザー名とパスワードが含まれていると考えてください。 「index.php」ページはログイン完了後のユーザーホームページ、「/project_name」ディレクトリ内のerror.phpページはログイン失敗後のエラー表示ページです。

ユーザーは、システムの他の部分を通じてユーザーのホームページ、/member/index.php ページへのアクセスを要求します。このとき、ページはユーザーの状況を決定します。ログインしているユーザーは、このページのコンテンツを直接表示します。セッションなどを確認できます); ログインしていないユーザーはログインする必要があります (/member/login.php にリダイレクト)、不明なエラーが発生しました (/error.php にリダイレクト)。また、それに応じて反応します。
ユーザーがログイン ページ (/member/login.php ページ) にリダイレクトされた場合、このページはユーザーのログイン情報 (ユーザー名とパスワード) を受け入れ、ログインが正しいかどうかを判断します。ユーザーが正しくログインした場合、ユーザーのホームページ /member/index に再びリダイレクトされます。ログイン エラーは /error.php にリダイレクトされます。
ユーザーがエラー表示ページ/error.php ページに誘導された場合 (上記のどのページから来たかに関係なく)、エラー メッセージが表示されます。



プロセス図は次のとおりです:





上記のテキストの説明と図に基づいて、MVC パターンの実装と組み合わせることで、これらのページのフレーム コードを簡単に作成できます:

見てみましょうまずシンプルに、ページ /error.php:

次に /member/login.php:

最後に /member/index.php:




(注: 上記のコードは単なる断片であり、プロジェクト全体を考慮し、デモ機能のみを考慮します)

コントローラーについて
まず、上記の 3 ページのコードが上記のコントローラーの制御/処理コードであることは明らかです。明らかに、これらのページには特定の操作は含まれておらず、Web ページ コードも含まれていません (これを見ると、これらのページの共通の特徴は、ページが充実していることです。 Web ページのテンプレートへの参照とオブジェクトの出力と取得を行い、そのメソッドまたはリダイレクトの 1 つを実行します。

詳細な説明については、pages/member/login.php のいずれかを選択してください。ページ全体は、フォームを送信するかどうかの判断によって、ユーザーが入力するログイン フォームの表示とログイン情報の処理の 2 つの部分に分かれています。前者として、Web テンプレート ディレクトリ/Templates 内のページに対応する member_login.dwt を直接参照し、解析後に出力します。後者として、まず Member オブジェクトを取得します (オブジェクトはビジネス ロジックの Member.inc.php から取得されます)。 directory/Include )を実行し、ログイン判定結果を取得後にリダイレクトします。このコントロール ページのコードでは、member_login.dwt がビュー ビュー/インターフェイスとして表示され、クラス Member がモデル モデル/ロジックとして表示され、ページ コード自体がコントローラー コントロール/プロセスになります。以下は、マークを追加する /member/login.php フレームワーク コードです:





(MVC モデルでのテンプレート クラスとそのアプリケーションについては、このサイトの別の記事「適切なテンプレートの選択」を参照してください。 PHP")

モデルについて
モデルについて話しましたが、ここでもう 1 つの重要なトピックがあります。それは、PHP プロジェクトにおけるクラスのカプセル化の適用です。

「クラスのカプセル化」という言葉に注意してください。これは、「オブジェクト指向」や他の「オブジェクトベースの設計」手法とは根本的に異なります。 「クラスのカプセル化」とは、クラスメソッドを使用してビジネスロジックを異なるクラスにカプセル化することだけを指します。したがって、ここでの「クラス」は、オブジェクト指向設計の採用によって出現する「クラス」、正確には「クラス」ではありません。 「ここでの「クラス」は、実際には、一連の関連する機能モジュールを結合した結果です。

なぜ単にオブジェクト指向アプローチを使用するのではなく、この一見何の変哲もないアプローチをシステム設計に使用するのでしょうか? PHPにはオブジェクト指向の機能はないのでしょうか？確かに、PHP にはそのような特徴がありますが、非常に不完全です (当サイトの別記事「Zend Engine 2.0 の設計図 (案) から PHP の将来を考える」を参照してください)。たとえば、PHP にはインターフェイスの概念や実装方法がなく、多重継承やメソッドのオーバーロードなどのオブジェクト指向の典型的な機能もありません。オブジェクト指向の設計手法を使用する必要がある場合、概要設計段階では非常に簡単に実行できるかもしれませんが、詳細設計段階はさらに退屈になり、運が良ければコーディング段階まで継続できれば、悲惨になるだろう。一方、システムにクラスの概念を導入せず、関数を使ってモジュールの機能を実装した場合、そのような「純粋なクラス」を使用した中規模および大規模システムでどれだけの関数が存在するかは想像できます。 」システム、これによって引き起こされるトラブルは非常に大きくなるのは明らかです。

PHP 言語そのものに戻りましょう。 PHP は実際のオブジェクト指向のサポートを提供しませんが、クラスとそのプロパティおよびメソッドの定義は提供します。その場合、クラス メソッドを使用して関連する汎用モジュールをカプセル化することを考えるのが自然です。これにより、一部のオブジェクト設計の利点を活用できるだけでなく、汎用モジュールを完全に使用することによる欠点の一部を回避することもできます。

(汎用モジュールを使用する一部のシステムでは、この方法が使用されます。関連する関数を同じファイルに記述して、参照するときに別のファイルを導入できるようにします。たとえば、ファイル Member.func.php には、ユーザー関連のすべての操作が含まれていますただし、この方法では、システム内の多くの関数のコード編成の問題が解決されるだけで、名前の競合の問題は解決されません。例で確認します。)

たとえば、上記のユーザーログインの例では、汎用モジュールメソッドが使用されている場合、コードは次のようになります:





そして、クラスカプセル化メソッドが使用されている場合、それは次のようになります:





おそらく、コードには違いがないと感じるかもしれません (汎用モジュールを使用したコードは、新しいオブジェクトを取得する必要がないため、より単純であるようにさえ見えます) が、本当の違いはインクルード ファイルにあります。汎用モジュール メソッドを使用して、関連する関数のコレクションをファイル内に編成し (一部のシステムではまだこれができないため、非常に混乱する状況が発生します)、クラス カプセル化メソッドを使用して、同じファイル名を持つ および クラスを宣言します (たとえば、 Member.inc.php で Member クラスを宣言するのと同様です。これは Java の規則に似ています)。これを使用する場合は、最初にそれをインクルードする必要があります (関数モジュールを使用していて、それが十分に整理されていない場合、おそらく人によっては「簡単に」 「すべての関数をすべてのページに含める - PHP は Java のようにコンパイルおよび実行されないため、これらの関数を解析するだけでも時間がかかります)。ただし、重要なのはクラス カプセル化メソッドを使用することです。呼び出しの場所を明確に示すことができます (メソッド)特定のクラス (メンバー) の (ログイン): これは、名前の競合を避けるという観点からは非常に効果的であり、コードの検査と保守にとってはより便利です。ページが複数の関数を完了する必要があるため、複数のファイルを含める必要があると想像してください。汎用モジュール メソッドを使用すると、関数呼び出しから関数自体が配置されているファイルを見つけるのは簡単ではありません (関数に関する統一ルールがない場合)クラスのカプセル化を使用する方法では、クラス名とクラス ファイル名に基づいてクラス メソッド コードの場所を正確に特定できます。 (そんな小さなメリットは大したことないと思われるかもしれませんが、メンテナンスプロジェクトを経てからは異論はないと思います。)

以上がクラスカプセル化方式を採用する理由です。システムの設計は最初のステップにすぎません。システム全体の設計を完了するときに、そこから学べることがたくさんあります。

デザインの一部にはオブジェクト指向のアイデアを活用できます。 PHP にはインターフェイスと抽象クラスの定義がなく、継承メカニズムは非常に不完全ですが、少なくとも基本的なクラス定義と単純な継承関係はあります。 「会社-従業員」や「販売者-商品-購入者」などの明白な関係は、クラスとクラス関係を通じてシステムで簡単に定義できます。 PHP ではこれができるので、実際の論理関係に従って定義するだけです。
システムによく現れるもう 1 つの状況は、個人とリストの関係です。これを理解するのは、BBS システム内の投稿リストと各投稿の間にあると想像するのが難しいかもしれません。設計の経験によれば、このような関係は PHP やその他の Web システムに多数存在します。このタイプの関係の場合、個人的には、Item と Items_List に対して次のクラス カプセル化メソッドを使用することをお勧めします:
Item クラス定義: Item.inc.php のコード
Item_List クラス定義: Item_List.inc.php のコード
PHP にはクラス メンバーに対する特別な要件 変数とメソッドには構文的なアクセス制限がないため (すべてパブリックです)、オブジェクトの使用時に混乱が生じる可能性があります。これに基づいて、この状況をコード アプリケーション レベルから制御するために、開発チームのコード仕様で規定することをお勧めします。
まず第一に、メンバー変数とメソッドのアノテーションを通じてそのプロパティを説明できるため、他の開発者が理解しやすくなります。このオブジェクトを使用する人は、自分の使用法が指定されたアクセス制限に違反しているかどうかを知ることができます。 (phpdoc などの自動ドキュメント生成ツールを使用する場合、開発者はクラスのソース コードを読まなくてもクラスのドキュメントを参照するだけで正しく使用することもできます。)
次に、メンバー変数のアクセス制限を考慮するため、いくつかの主要で頻繁に使用される変数を使用します。 (コメント内で) アクセスまたは変更する必要があるものは、パブリックとして宣言されます。このアプローチにより、get() メソッドと set() メソッドの多くのコードを節約できます。これは他のオブジェクト指向言語では非常に醜いと考えられていますが、このような使用法が合理的である限り、PHP は Java ではないことに注意してください。大胆に。
上記のコード例からコメントの割合に気づいたかもしれませんが、コメントの重要性は誰もが理解していますが、それでも言及する必要があります。この例では Javadoc スタイルを使用しており、既存のツールを使用してドキュメントを直接簡単に生成できます (もちろん、開発チームが独自の適切なコメント スタイルやドキュメント生成ツールを定義することもできます)。システム アナリストにとって、設計フェーズが完了した後に開発パートナーに提供するコードの一部は、これらのコメントのほとんどが含まれるフレームワーク コードである可能性が高く、エンドレスなダイアグラム以外のコミュニケーション ツールとなります。これらのプログラマーが最もよく知っているコメント。



PHP システムのクラス設計には、オブジェクト指向システムの構築のようなさまざまな合理的なパターンの介入は必要ありません (また、そのような「コスト」もありません) が、それでもある程度の考慮は必要です。論理的合理性と運用の実現可能性は両方ともテスト基準です。

(クラス設計といえば、PHP 開発に適した IDE についても考えました。私の知る限り、より専門的なものとしては、Zend が提供する Zend IDE が挙げられます。また、JBuilder を使用した PHP 開発ツールとして、JBuilder の開発ツールとして登場するものもあります)ツールを開きます。ただし、最も一般的に使用されるのは PHPEd や UltraEdit のようなエディターです。既存のエディターが PHP のクラス設計とコード実装を非常にスマートにサポートできれば理想的です。)

最後にお話しするのは View です。ただし、一部のコンテンツは Web デザイナーに関連していますが、PHP プロジェクト (およびその他の Web プロジェクト) に取り組んでいるシステム アナリストもこのトピックに注意を払う必要があります。 MVCモデルを適用することで、これまでのようにWeb開発者とプログラマのそれぞれの作業結果が影響し合うことがなくなり、自然とそれぞれの作業効率が向上することがわかります（相互関係が以前より調和する可能性があります）。しかし、システム アナリストにとって、ユーザー インターフェイスを個々の Web ページ テンプレートに分割するには、多くの分析作業が必要になります。

最初のステップは、システム全体の流れを決定することであり、これはシステム設計の初期段階で行う必要があります。ビュー ビュー/インターフェイスとコントローラー コントロール/プロセスの場合、必要なすべてのページがこのプロセスを中心に生成されます。ただし、通常、この時点でフローチャート上で確認できるのは、さまざまなページ間で受け渡される関連パラメータのみであり、各ページに表示されるコンテンツを理解することはできません。これは、ユーザー インターフェイスを分析する次のステップです。

ユーザー インターフェイスを分析する作業では、最初のステップとして各ページのコアと、プロセスを完了するために不可欠なユーザー インターフェイス要素 (フォームとフォーム フィールド、リンクなど) を決定します。ページコンテンツに表示する必要があるナビゲーションを決定し、最後にプロセスに従ってレビューする必要があります。例として上記のユーザーログインを見てみましょう。キー ページ /member/login.php の場合、最初に決定できるのは、ユーザーが送信する前と送信した後にフォームを表示することです。このフォームにはユーザー名とパスワードを入力するための 2 つのテキスト ボックスが含まれています。プロセスによると、このページでは、アプリケーションにユーザー インターフェイスは必要ありません。代わりに、コントローラー コントロール/プロセスのロジック層がリダイレクトに使用されます。 2 番目のステップでは、ページ (正確には、ログイン フォームが表示されるとき) に提供する必要があるナビゲーション リンクを作成する必要があります。ここでは、システムのホームページまたは他の未登録ユーザーの開始点へのリンクを追加できます。ページ (ログインをキャンセルするユーザーの一時的な決定を容易にするため) と、既存のユーザーをログアウトするためのリンク (ログインしているユーザーの場合)。見直してみると、この設計では、ログイン前に管理者ログインと一般ユーザーのログインをより適切に区別することが考慮されていないように見えるかもしれません。その後、フォームに隠しフィールドを追加して、ログインを選択したユーザーかどうかを示すことができます。 in は、管理者または一般ユーザーとしてログインするために用意されています。

ユーザー インターフェイスの要素を決定した後、これらの分析結果を制作のために Web デザイナーに引き渡すことができるという意味ではありません。つまり、その後の各ページのテンプレートに必要な変数名の開発という最も重要なステップが実行されていません。分析が完了しました。上記のユーザー ログインの例では、システムに以前にログインしたユーザーを識別し (前回の訪問中にクライアントに設定された関連する Cookie 値に基づいて)、このユーザー名をログインのユーザー名列に表示する機能がある場合、 member_login.dwt の設計では、フォーム フィールドにテンプレート変数 ({USERNAME} など) が割り当てられることを示しています。このステップが完了したら、制作のために Web デザイナーに引き渡すことができます。

コーディング段階では、一部のローカル システム設計を変更する必要がある場合があり、これには Web ページ テンプレートへの変更が含まれる場合があり、慎重に扱う必要があることに注意してください。

コード構成に関する追加の注意事項
上記で説明されていないファイルとディレクトリがいくつかあります:

config.inc.php -- phpMyAdmin または phpWizard.net によってリリースされた他のプロジェクトに精通している場合は、その目的が非常に明確であるはずです。このファイル: このプロジェクトのスコープ内でグローバル変数を定義します (各ページに含まれています)。私自身、これは非常に良いデザインだと思うので、プロジェクトへの適用も推奨しています。さらに、プロジェクト内の他の変数との競合を確実にするために、ファイル内で複数の配列を定義することをお勧めします。さまざまなグローバル変数は配列の特定の値として表示されます。これにより、チームの他の開発者は、config.inc.php に表示されるすべての変数名を回避するのではなく、1 つの変数名のみの使用を回避することが容易になります。このファイルを使用するもう 1 つの利点は、主要な変数 (サーバー環境に関連する変数など) が集中的に定義されるため、プロジェクト全体を簡単にインストールおよび移植できることです。
security.inc.php -- 名前が示すように、このファイルはシステム全体のセキュリティ ポリシーを制御および実装します。セキュリティの問題に関しては、2 つの制御スキームが考えられます。1 つは各制御プロセス ページの先頭でこのページを制御する方法、もう 1 つは制御ファイルを使用してプロセス全体を制御し、それを各制御プロセス ページに追加する方法です。私は個人的に後者のアプローチを支持しています。その理由は非常に単純です。定義が簡単で、保守が簡単です。各ページを個別に定義する場合と比較すると、多少効率は落ちるかもしれませんが（セキュリティ制御が必要ない一部のページもファイルを含めて判定する必要があります）、得られるのはシステム全体のセキュリティ制御とコードの利便性です。メンテナンス (if.​​..else... の判断を失うことは、そのような結果と引き換えに価値があります)。
/Temp -- 明らかに、このディレクトリに存在するものはすべて一時ファイルであり、このディレクトリはプロジェクトの正式にリリースされたバージョンには実際には表示されません。開発中に一部の関数の使用方法がよくわからない場合、または関連する経験のないコードをテストする場合は、このディレクトリにファイルを作成できます。このディレクトリはプロジェクト コード内にあるため、非常に便利です。実行中のプロジェクトのコンテキストを取得するのに便利です。実験コードのコストを大幅に削減します。
/admin -- 通常、システムのバックグラウンド管理コンテンツは別のディレクトリに配置する必要があります。私は個人的には admin という略語を好みます (もちろん、システム アナリストが推測しやすい管理ディレクトリ名を使用すべきではないと考える場合もあります)。システムセキュリティのための最初の保護層の数を増やすように設定できます)。
/css および /scripts -- Web デザイン、つまり View/interface に関連するファイルの保存場所であり、それぞれスタイルシートとクライアント側のスクリプトです。これを行うことの利点については、Web サイトのプランニングに関する本で必ず言及されます。



オプション 2: シンプルな Web サイト プロジェクト
システムのパフォーマンスは、このタイプのプロジェクトで追求される主な目標であると同時に、システムのメンテナンスや拡張もあまり考慮せずに行うことができます。 (この文は少し絶対的なように聞こえるかもしれませんが、顧客のニーズとプロジェクトの性質から判断すると、顧客のニーズをできるだけ短期間で満たし、システムを効率的に稼働させることが、プロジェクトを成功させるための最良のテスト基準です)したがって、おそらくこの Class プロジェクトは PHP ハッカーにとって天国なのかもしれません (私はかつて PHP の使用効率を追求しすぎる人間でした)。この種のプロジェクトの特殊性から、ここで説明する範囲はシステム設計に限定されず、プロジェクト チームの設立からプロジェクトの実行までのプロセスです。

最初に注目すべきは、プロジェクトに関わる候補者です（これはプロジェクトマネージャーの責任かもしれませんが、PHPプロジェクトの特性を最もよく知っているシステムアナリストが参加する必要があります）。 PHP 開発者に関しては、少なくとも PHP のさまざまな機能に精通している開発者を選択する必要があります (この種のプロジェクトは、社内にまだ参加する開発者をトレーニングする実際のプロジェクトとしては適していません)。 PHP をソースコードレベルで理解できる人であれば、より理想的です (ただし、一般的な PHP 開発会社では通常不可能です)。 Web デザイナーに関しては、クライアント側 (JavaScript など) とサーバー側 (できれば PHP) のスクリプトに精通している人を選ぶのが最善です。これは、このタイプのプロジェクトの主な特徴は、単一の Web ページに次のような特徴があるためです。大量のコードと Web ページのコード (通常は HTML)、クライアント側のスクリプト (JavaScript など)、およびサーバー側のスクリプト (PHP など) が混在するため、さまざまなスクリプト言語を理解する Web デザイナーを追加するのが目的ではありません。チームの PHP 開発能力を向上させるためですが、Web ページの変更がプログラマーの作業に影響を与えることを避けるためです。

2つ目はプロセス指向、正確に言うとページ指向のシステム設計です。最初のタイプのプロジェクトに比べて、このタイプのプロジェクトでは顧客のニーズが非常に明確であり、一般に、Web 開発に長く従事している企業は、このタイプの Web サイトプロジェクトに対する一定のデザイン経験の蓄積も必要です。顧客のニーズに完全に応えるためには、各ページの入力パラメータや出力コンテンツ (Web ページに表示されるナビゲーション リンク以外の機能リンクも含む) を含むシステム全体のプロセスに焦点を当てて設計する必要があります。システムのセキュリティポリシーを決定する このタイプのプロジェクトでは、主にユーザーレベルとページアクセス権限を決定し、実装方法を決定します。ただし、このようなプロジェクトがコーディング段階から設計段階に戻ることは珍しいことではなく、ローカル設計 (ページ受信パラメーターや出力リンクなど) への変更は適時に制御する必要があることに注意してください。

最後のステップは、コードとデータベースの最適化です。このようなプロジェクトでは、開発者のハッカーとしての姿勢を適切に奨励する必要があります。推奨されるアプローチは、システム アナリストが各ページの疑似コード (フレームワーク コード) を提供し、部分的な実装は個々のプログラム開発者や Web デザイナーが実行することです。

PHP コードでは、通常、次の側面が考慮されます:

アルゴリズムの選択と関数の実装方法: モジュールレベルの最適化は、複数の開発者によって議論され、解決されます。
関数の使用: コードレベルの最適化。開発者はさまざまな機能を明確に理解し、少なくとも機能マニュアルを参照する習慣を身に付ける必要があります。
データベースへのクエリと変更は SQL ステートメントを使用します。社内に関連するデータベース システムの管理者がいる場合、いくつかの最適化を行うことができます。 質問についてはアドバイスを求めてください。
回避すべきその他の問題: コードのコピーやその他の不適切なコードの状況。



私の経験によれば、この種のプロジェクトで通常書かれるハッカーコードは次のとおりです:

特に検索アプリケーションでのループステートメントの使用: このとき、while と for ( の違いに注意してください)大学では誰もがこの種のプログラムを授業で行ったことがあると思います)。これも良いプログラミングの習慣です。
SQL ステートメントの最適化: まず、効率を向上させるための非常に重要なポイントです。 、いわゆる単純なステートメントを再度使用するのではなく、数行のステートメントを恐れずに、クエリ ステートメントによって返されるフィールドを慎重に検討して、不要なデータを減らしてください。
チェックボックスやテキストフィールドなどのフォーム送信値の取得。フォームのフィールド名を賢く設計すると、コードの量をある程度減らすことができますが、送信された値の処理方法にも注意する必要があります。



このようなプロジェクトではコードをハッキングすることが推奨されていますが、各コードの横にできるだけ詳細なコメントを含めることが最善です。

このタイプのプロジェクトの特殊性により、プロジェクトを完了するための鍵はシステム設計段階だけではないため、プロジェクトの開始、システム設計、コーディング、テスト、納品のプロセスについて簡単に説明します。

プロジェクト チームを形成する適切な人員を選択し、営業スタッフやアカウント担当者の追加を検討してください。
システム アナリストは、予備的なセキュリティ戦略を決定しながら、システムに必要な各 Web ページを簡単に要約し、顧客のニーズと以前のプロジェクト経験の組み合わせからその機能を説明できます。営業担当者とアカウント担当者をこのステップに追加できます。 (この時点で、Webデザイナーは顧客に提供する一連のWebサイト画像ページを準備しています。)
詳細設計では、各ページの位置と名前を決定する必要があります。それよりも重要なのは、入力を決定する必要があります。パラメータと出力コンテンツ、および Web ページに対するさまざまなレベルのユーザーの正確なアクセス権。データベースの設計も行います。この段階が完了したら、少なくともシステム フローチャート (アクセス許可の識別を含む) とデータベース設計情報を提供する必要があります。
Web デザイナーとプログラム開発者は関連情報を入手し、独自に作業します。前者の場合は、顧客が認識した一連の画像に従って各ページをデザインします。後者の場合は、「エキサイティングな」コーディング作業を開始します (現時点で必要なのは効率的で短いコードハッカー コードであるため)。この作業段階で問題が発生した場合は、システム アナリストにフィードバックする必要があります。システム アナリストは、設計を変更するために上記のステップ 3 またはステップ 2 に戻ることができます。
プログラミングと Web デザインの後は、統合期間が必要です。これは、プログラム開発者がコードを自己テストする段階でもあります。同時に、この段階でコード (Web ページ コードやプログラム コードを含む) とデータベースの最適化を実行できます。このフェーズの終了時には、完全なシステムが利用可能になるはずです。
実際のテスト段階は通常比較的急いでおり、企業はこの分野で技術と経験の一定の蓄積も持っている必要があります（可能であれば、安定性とストレス耐性をテストするためにいくつかのソフトウェアツールを使用したいと考えています）。最後のステップは、顧客がテストできるように Web アクセス可能なアドレスを提供することです。このフェーズが完了すると、システムは正式に顧客に提供されます。



オプション 3: 包括的な Web サイト プロジェクト
すでに、主な開発言語として PHP を使用している大規模な Web サイトがいくつかあります。このタイプのプロジェクトでは、純粋に PHP テクノロジーの観点から言及する価値のあるトピックはあまり多くありません。つまり、上記で提案した 2 つのプロジェクト設計方法を選択するか、各部分の実際のアプリケーションに基づいて総合的に使用するのが良いでしょう。ウェブサイト（アクセス強度、操作動作など）また、私の個人的な経験によれば、純粋な技術よりも、プロジェクト チームの組織と調整、プロジェクトの各フェーズ完了後のメンテナンス作業が重要な要素となります。

このタイプのプロジェクトの場合、プロジェクトを迅速かつ高品質で完了するには、いくつかのオープンソース ソフトウェアを適切に採用することが非常に有益であると考えられます。プロジェクトの特定の部分では、オープン ソース ソフトウェア プロジェクトの設計やコードを直接導入できますが、その前提として、システム設計者はこれらの導入されたプロジェクトをよく理解し、これらの孤立したオープン プロジェクトをうまく接続する必要があります。ソース プロジェクトとプロジェクト全体 (セキュリティ ポリシーの考慮事項やグローバル変数への参照など)。

たとえば、顧客の要件に応じて、包括的な Web サイトには次の機能が必要です:
複雑なニュースリリース;
管理機能がほとんど必要ないオンライン フォーラム;
ユーザー管理が必要。



(明らかに、これは企業 Web サイトのプロトタイプです。)

項目 1 と 2 は明らかにいくつかの成熟したオープンソース ソフトウェア プロジェクトから借用できますが、項目 3 は単純な顧客のニーズのため、独立して開発した方がコスト効率が高くなります。 。この観点から見ると、項目 4 はシステム全体の最も重要な部分です。ユーザー管理を項目 1 と 2 で使用されるオープンソース ソフトウェア プロジェクトと統合する必要があります (項目 3 は独立した開発のため、統合が非常に簡単です)。 。 (技術蓄積が優れている一部の企業では、上記の統合部分のシンプルなソリューションも用意しているため、そのような Web サイトプロジェクトを完了するためのコストは非常に低くなります。)

いくつかの特別な機能ポイント
さらに、通常表示される機能ポイントがいくつかあります。プロジェクト内ではありますが、適切に処理する必要があります:

1. データ リストのページング。
この機能については、インターネット上に中国語や英語の資料がたくさんあります。特定のテクノロジーと実装の詳細については、これ以上説明する必要はありません。ここで指摘しておく必要があるのは、次のとおりです。

A. 特定のツール クラスまたはその他の再利用可能な形式のメソッドをカプセル化することをお勧めします。これには次のような利点があります。システム内にデータ リストのページングがある限り、ほぼ同じコードの束が表示されます。

B. 高効率の要件を持つ一部のプロジェクト (上記の「単純な Web サイト プロジェクト」タイプなど) を対象としている場合は、特定のデータベース システムおよびデータベース システムに関連する結果セットのインターセプトに対して PHP 独自の操作関数を直接使用する必要があります。 MySQL の「LIMIT start, offset」などのテクノロジ (SQL ステートメント)、一般的なデータベースの場合、きちんとした合理的なシステム設計が必要なその他のプロジェクト (前述の「多数のビジネス ロジック プロジェクトの設計」など) used インターフェイス。複数のデータベース システムとの互換性を確保するために、このインターフェイスを使用して、効率を犠牲にしてシステムの保守性とスケーラビリティを向上させる代わりに、結果セットのフィルタリングを完了できます。つまり、データ リスト ページングを実装するために特定のデータベース操作関数を使用するか、サードパーティの汎用データベース インターフェイスを使用するかにかかわらず、システム パフォーマンスと拡張要素の両方を考慮する必要があります。

2. エラー制御。
これも上で触れました。ツール クラスに属するエラー クラスを確立することに加えて、専用のエラー表示ページを確立することをお勧めします。このページは、静的 HTML ページ (ユーザーへの謝罪とエラー後の処理手順を表現する) または動的 PHP ページ (エラーの特定の原因と場所、その他のより詳細な情報を含めることができる) のいずれかにすることができます。この情報を提供するためのシステム セキュリティ ポリシーの許可)。エラー クラスの役割は、通常のプログラムによってスローされたエラーを受け入れ、必要な処理を実行し、情報をまとめてエラー表示ページにリダイレクトすることです。



同時に、エラーページを確立すると、開発段階において、try{…} catch{…} ブロックと同様の例外制御が欠けている既存の PHP の欠点を補うことができます。デバッグ中にエラー クラスを介してエラーまたは出力をスローし、それを表示します。

3. アップロードとダウンロード。
PHP の場合、アップロードの実装には、他の一般的な Web 開発言語のようなサードパーティ プログラムのサポートは必要ありません。組み込みのメカニズムは非常に簡単に処理できます。ただし、ここで説明するのは、いくつかの複雑なアップロード機能の実装です。添付ファイルを処理するための次のプロセスを調べてください:




この機能を使用すると、ユーザーは新しいメッセージを作成するときに他のファイルを添付でき、メッセージを送信する前に任意にファイルを削除したり追加したりできます。この需要は多くのオフィス関連システムに反映されるため、経験豊富なシステム アナリストとして、この種の機能の実装計画はシステム設計段階で作成する必要があります。たとえば、図に示すプロセスでは、実際には 1 つ以上のフォームを相互に送信することで完了します (具体的な設計については詳しく説明しませんが、関連する PHP ファイルのリファレンスが提供されています。別の直感的な例として、ほとんどの無料電子メール システムの機能には添付ファイルが含まれているため、興味があればチェックしてみてください)。

ダウンロードに関しては、最も簡単な解決策は、サーバー上の Web アクセス可能なディレクトリにファイルを配置し、訪問者に実際のファイル パスを提供することです。ただし、一部のシステムでは、ファイルのダウンロードに特定のセキュリティ ポリシーに基づく本人確認が必要です。ダウンロードした場合、この方法には隠れた危険が伴います。通常のアプローチは、ファイルを Web アクセス可能なディレクトリの外部のサーバー ファイル システムに配置するか、データベース システムに保存することです。どちらも、ファイルの内容を取得して要求元のユーザーに直接返すための単純なプログラムが必要です (これには、 HTTP 出力ヘッダーの問題に注意してください。具体的な説明ではなく、PHP ファイルを提供してください)。システム設計時のさまざまなニーズに応じて、対応する方法を採用できます。

4. クライアント セッションの維持
PHP の既存のバージョンにはセッションのサポートが組み込まれており、この方法は通常プロジェクトで使用されます。特別なニーズを持つ一部のプロジェクト (配布システムなど) では、より複雑な処理方法が使用される場合があります。

クライアント側では、通常、Cookie は特定の顧客を識別するために設定されます。Cookie をサポートしていないクライアントに対処するもう 1 つの方法は、URL 書き換えを使用して、特定の顧客を識別するのに十分な文字列を追加することです。この側面から見ると、PHP の組み込みセッション サポートを使用するのが最も理想的です。これは、クライアントで FALLBACK を自動的に実行できるためです。クライアントが Cookie をサポートしている場合は、Cookie がサポートされていない場合は、URL 書き換えを使用します。 - 開発者の介入を必要としないすべて。他のセッション処理方法を使用する場合、またはニーズに合わせて独自のセッション ライブラリを作成する場合、注意する必要があるのは、クライアント側のデータ ストレージの問題 (Cookie、URL 書き換え、またはその両方) に対処する方法です。

サーバー側では、簡単に言えば、文字列でマークされた特定の顧客ごとに関連するデータを保存するだけで済みます。使用できる方法はたくさんありますが、一般的な方法はファイルとデータベースです。 PHP の組み込みセッション サポートでは、デフォルトのサポート方法は、各顧客がシステムの一時ディレクトリまたは指定されたディレクトリにデータを保存するファイルを作成することです。もちろん、データベースやその他の方法をサポートするように設定を変更することもできます。セッション ライブラリを自分で作成する場合は、システムのニーズに応じて適切な保存方法を選択するだけです。分散システムの場合、サーバー側のセッション情報を共有する方法には細心の注意が必要であることを指摘しておく価値があります。

さらに、セッション変数を設定する場合、PHP の組み込みセッション ライブラリはオブジェクトを変数値としてサポートします (実際には、一般変数、配列、オブジェクトを問わず、すべての変数値はシリアル化後に保存されます)。が利用可能です:





これは、上記で説明した一部の商用システムにとって有益です。まず、ユーザーに関するオブジェクトをセッション変数値として使用して、複数のセッション変数の代わりに、一連の情報を保存できます。第二に、ショッピング カートに似た機能がある場合、システム全体の設計 (つまり、商用システムの設計方法) と非常に一致した方法でショッピング カート オブジェクトをセッションに組み込むことができます。上で説明したように、クラスのカプセル化を強調しています)。

5. ...特定のプロジェクトに関連するその他の機能ポイント...
これらの機能ポイントは、システム設計段階で予測して解決できれば良いですが、少数の未発見の機能ポイントがあっても問題ありません。コーディング段階に任せる -- 通常、このような省略はシステム全体のアーキテクチャには影響しません。設計段階に戻って、対応するコンテンツとドキュメントを追加するだけです。結局のところ、関連プロジェクトの経験が浅いシステムアナリストにとって、設計段階でそのような機能ポイントを完全に理解することは非現実的です。

他の人について
かつては PHP について多くの議論がありましたが、Web における Java の利点がますます多くの人々の認識になって以来、そのような議論は下火になりました - 全員が合意に達したようです - PHP は厳密な作業にとって非常に重要 商用システムは依然として無力です。しかし、これを理由に商用システムへの PHP の適用を盲目的に否定することは客観的ではありません。結局のところ、PHP には低コスト (ここでのコストには開発コスト、使用コスト、保守コストが含まれます) という利点もあります。この記事の目的は、いくつかの PHP システム設計方法を説明するだけでなく、一部の開発者や企業が PHP を使用して適切な商用システムを構築するよう誘うことも目的としています。

さらに、この記事は私自身の経験の一部にすぎません。これを読んであなた自身のアイデアがあれば、喜んで共有します。それは、商用サポートなしでオープンソース ソフトウェアの開発を促進することができます。結局のところ、それは非常にエキサイティングなものです。 (これに関連して、Sun Microsystems が J2EE 向けにリリースした Blueprint や Java Pet Store のように、PHP 開発に関するドキュメントやデモンストレーション プロジェクトを書きたいとさえ思っています。残念ながら、それは時間、エネルギー、個人の能力によって一時的に制限されています。おそらく春節です。休日は良い機会です:)

参考資料

この記事で言及されている記事とコード
コード: ユーザー ログイン インスタンス (コントロール ページのindex.php、login.php、Web テンプレート member_index.dwt、member_login.dwt、ロジック クラスを含む) Member.inc.php) 関連の添付ファイル;
コード: クラスのカプセル化インスタンス (Item クラスの定義 Items.inc.php、Item_List クラスの定義 Item_List.inc.php) 関連の添付ファイル;
コード: アップロード インスタンス (コントロール ページ add.php 、attach) .php) 関連添付ファイル;
コード: インスタンスをダウンロードするための関連添付ファイル (コントロール ページ download.php);
コード: サンプル コード構成内の 2 つのグローバル ファイル (config.inc.php、security.inc.php) の関連添付ファイル;
記事: PHP の将来について;
記事: PHP でのテンプレートの使用。
その他の参考資料
PHP 公式 Web サイト - http://www.php.net
ソフトウェアとドキュメント、使用方法などが記載されています (この記事が書かれた時点での最新のトレンドは、主要なバージョンの PHP 4.1.0 のリリースでした)いくつかの点で改善されます）。
PHP の商用サポートを提供する Zend 会社 -- http://www.zend.com
PHP 関連のツールとテキスト資料が含まれています (この記事のトピックに関連するトピックがいくつか見つかります)。
有名なオープン ソース プロジェクト Web サイト SoureForge -- http://www.sourceforge.net
オープン ソース プロジェクトが集まる場所で、Web ベースのさまざまな便利なツールを提供しています (PHP で書かれたプロジェクトが何千も見つかります)。