Web ページ全体に 1 つのファイルを使用することの長所と短所は何ですか?[閉まっている]
質問
どう表現したらいいのか分かりませんが、やってみます。
最近オブジェクト指向 PHP でポートフォリオのコーディングを開始しましたが、SQL データと $_GET 変数に応じてコンテンツが変化する単一ページを使用することがベスト プラクティスに従っているかどうか疑問に思っています。
そうである場合、そうでない場合、その理由は何ですか?
編集:より詳細な詳細については、次の投稿をご覧ください。
解決
単一のファイルがすべてのリクエストを処理するフロント コントローラー パターンの使用について質問していますか?多くの場合、これは、index.php と mod_rewrite ですべてのリクエストを取得し、URL の残りの部分がクエリ文字列のパラメータとして指定されて行われます。
http://www.onlamp.com/pub/a/php/2004/07/08/front_controller.html
私は、このパターンをアプリケーションに使用することをお勧めします。これは、認証などを単一の場所で処理できるためであり、多くの場合、新しい機能をコントローラーに登録されたクラスにするなど、より厳密なレベルで物事を統合する必要があるからです。何らかのメカニズムを介することは非常に理にかなっています。
他の人が言及した URL に関する懸念は、実際には正確ではありません。Web サイトを構築する古代の技術を使用していない限り、URL 構造とファイル構造の間に実際の関係はないからです。Apache の機能の大部分は、ファイル/ディレクトリ構造と URL 構造が別個の概念 (エイリアス モジュール、書き換えモジュール、コンテンツ ネゴシエーションなど) であるという概念に基づいています。
他のヒント
- スケーラブルではない
- コードの管理が難しい
- パーサーはすべてを解析する必要があります
- コードの匂いの完璧な例
- 1 つのエラーでサイト全体がクラッシュする
単一のランディング ページを意味する場合 (例:Index.php) を作成し、セッション変数などを使用します。どのコードを含める必要があるかを判断するには、はい、これはよく使用される手法です。
編集:上記の意味は、ダニエル・パパシアン氏が優れた投稿で詳細に説明していることを意味します。
HTML、SQL、PHP をすべて 1 つのファイルに配置するということであれば、GateKiller が指摘した理由により、そうではありません。
Actaul ページ ファイルには、そのページに関してサイト上の標準の「ページ」と異なる点のみを含める必要があります (たとえば、ページ タイトル、インデックス ページには最新ニュースを取得するためのコードが含まれる場合など)。複数の場所で使用される (または使用される可能性がある) ものはすべて、外部 php ファイルに移動して含める必要があります。例は次のとおりです。
- データベース情報 (パスワード、ユーザー名など)
- ヘッダー/フッター
- ログインコード
これにより、コードの管理がはるかに簡単になります。たとえば、データベースのパスワードを変更した場合、更新が必要なファイルは 1 つだけです。または、ヘッダーにバナーを追加することにした場合も、変更が必要なのはすべてのページではなく 1 ページだけです。
また、新しい機能を追加する作業も大幅に軽減されます。たとえば、新しいページは次のようになります。
<?php
require ('config.php')
require ('start.php')
require ('header.php')
//custom page stuff
require ('footer.php')
?>
または、Cookie を介した自動ログインを追加するには、Login() 関数 (Cookie の作成) と start.php (Cookie の確認 + Login() の呼び出し) を変更するだけです。
また、将来的にこれらのファイルを他のプロジェクトに簡単に転送することもできます。
ゲートキラーが言及したすべてに加えて、遅延バインディングも利用できません。
- コードの管理が難しい
バージョン管理を使用している場合、サイトの単一の「ページ」に発生した可能性のある変更をロールバックするのは非常に困難になります。その後に来る可能性があるものについてはマージし直す必要があるため、
modリライトを使用しない限り、検索エンジンにはあまりフレンドリーではありません
私はほとんどの意見に同意しません。サイトがカスタム CMS などで管理されている場合、1 ページを使用しない理由はありません。
私は少し前に作成した CMS で同様のことを行いました。すべてのクライアントには、テーマ、コンテンツ、添付ファイル、およびメンバーのアクセス許可をデータベースに照会する 1 つのdefault.asp ページがありました。変更を加えるには、変更を一度だけ行い、変更が必要な場合は他のクライアントにその変更をコピーしました。
もちろん、これはほとんどのシナリオでは機能しません。ウェブサイトでさまざまな処理を行う場合 (私の cms は、ページの読み込み中に特定の機能を繰り返しただけです)、複数のページを作成することが実際に唯一の方法です。
興味のある方のために、これとまったく同じモデルを使用するフレームワークがあります。元々は ColdFusion 用でした。この方法論にはまだコミュニティがあり、バージョン 5.5 は約 1 年前 (2007 年 12 月) にリリースされました。
このスクリーンダンプと次の説明は、現時点でのコードがどのようなものであるかをよりよく理解できるかもしれません。
私は、「インターネット フレンド」のダニエル・パパシアンや他の数人が言及しているモデルと同じモデルを使用しています。フロントコントローラー。
私のインデックスページはこんな感じです。
require_once 'config.php';
require_once 'class_lib/template.php';
$template = new template($config);
$template->dataQuery();
$template->pageCheck();
$template->titleAssembly();
$template->cssAssembly();
$template->metaAssembly();
$template->menuAssembly();
$template->content();
echo $template->publish();
クラス構成体はメイン テンプレート ファイルを開き、タグを生成されたコードで置き換えることによって各メソッドで操作できる変数にそれを読み込みます。醜い URL は、mod_rewrite を使用してクリーンアップするので、実際には問題ではありません。
ただし、Papasian にも一理あり、この方法は Web ベースのアプリケーションなどに適しています。
最初の質問があまり具体的でなくて申し訳ありません。
さらに、手助けのために数行投函してくださった皆様に、大きな「感謝」を申し上げます。
私はよく .php 拡張子のない php ファイル (サイトなど) を使用し、
<Files site>
ForceType application/x-httpd-php
</Files>
Apache にファイルを php ファイルとして解釈させる .htaccess に追加します。
URL 内のファイルに vars を解析できます。 http://www.yourdomain.com/site/var1/var2/var3
使用
$var_array = explode("/",$_SERVER['REQUEST_URI']);
$var1 = $var_array[1];
$var2 = $var_array[2];
$var3 = $var_array[3];
varを取得します。こうすることで、modrewrite を行わずに、searchengingfriendlyurls を含む 1 つのファイルを使用できます。
再:URLとファイル構造
すべてのコンテンツがデータベース内にあり、index?p=434 モデルでアクセスされるサイトを変換しました。データベースを使用する利点はなく、ブラウザでコンテンツを編集する必要があり、ページは単なる数字であったため、コンテンツを追加する必要があるユーザーにとってサイトは混乱しました。
すべてのコンテンツを取り出して、別のファイルに入れました。それぞれに分かりやすい名前が付けられ、フォルダーに整理されていました。各ファイルは次のようになります。
require('sitelib');
do_header('about', 'About Us');
// content here
do_footer();
クライアントはそれを気に入ってくれました。彼らは、任意の HTML エディタを使用して、適切なファイルを見つけて変更を加えることができました。そして新しいページを作ることができました。すべて言えること:URL とファイル構造を一致させると便利な場合があります。