1

私はこれまで、PHP コーディングに対してモノリシックなアプローチを使用してきました。

つまり、平均サイズが 70k ～ 250k の index.php を 1 つ作成し、

mod_rewrite

残りの部分を回します

REQUEST_URI

何が起こっているかを制御するためにindex.phpに渡されるパラメータに。

別の方法は、それぞれが特定の目的に特化した多数の小さな php スクリプトを作成することです。私のよりアクティブな ajax スクリプトのいくつかは、この恩恵を受ける可能性があると考えています。

この思考プロセスに私を留めていることの 1 つは、インクルードの使用、特に条件付きインクルードがオペコード キャッシュのパフォーマンスにどのように影響するかがわからないことです。

私は一般的に、これについてのパラノイアのために、可能であればインクルードを完全に避けてきましたが、これはコードを複製するか、モノリシックのままにすることになります。

とにかく mod_rewrite を使用しているので、2 つの方法論間の変換は簡単なはずです。

コメントをお待ちしております。

編集: 私の対象アプリの 1 つは、現在、1 秒あたり 80 ～ 100 ページのヒットを処理しています (適切なハードウェアを入手しました)。それらのほとんどは ajax リクエストです。すべてが機能し、きびきびと動作しますが、私は php プログラマーとして批評せずに開発しており、必要としています。

4

5 に答える 5

6

モジュラー コードは、理解しやすく、維持しやすいものです。巨大なモノリシック コードベースは、トランプの家のようになる可能性があります。実際には問題なく動作しますが、下位の要素を変更することは不可能になります。コードを明確な抽象化に分割すると、変更がはるかに簡単になり、開発者を追加した場合でも悪夢を避けることができます。

于 2009-10-13T21:18:13.413 に答える
3

インクルード ファイルを使用しないことによるパフォーマンスの向上は、インクルード ファイルを使用した大規模なアプリケーションの保守とデバッグの容易さよりもはるかに重要です。

手直しは無駄。あるアプリから別のアプリにコードをコピーして貼り付けるのは、メンテナンス地獄です。

于 2009-10-13T21:21:41.043 に答える
1

他のコメント (私は完全に同意します) に加えて、別の見解: モノリシックなアプローチは、極端に進めば貴重な RAM を消費するという経験をしました。それからのすべてが必要かどうかに関係なく、それだけで、インスタンスごとに得られる 8、16、または 32 MB から多くを消費します。

于 2009-10-13T21:41:53.303 に答える
0

Unix コマンド ライン スクリプトの場合、モノリシックなアプローチにより、非常に高いレベルの移植性が実現します。

単一の（ハッシュバン）スクリプトを使用すると、スクリプトをダンプすることもできますusr/bin

sudo cp myprog /usr/bin
/* (...) */
sudo cp myprog /usr/games
/* (...) */

myprogこれにより、 の代わりに ,と入力するだけで、どこからでも任意のパスからプログラムを呼び出すことができます/PATH/./myprog。それが信頼できることを確認してください！

パスには特別な注意を払う必要があります。

パスに関するいくつかの簡単な例:

/* Create a folder in the home directory, named as the script name, if not existing. -*/
if (!is_dir($_SERVER["HOME"]."/".$_SERVER["SCRIPT_NAME"])){
  @mkdir($_SERVER["HOME"]."/".$_SERVER["SCRIPT_NAME"]);
}

/* Program folder path: --------------------------------------------------------------*/
$PATH = $_SERVER["HOME"]."/".basename($_SERVER["SCRIPT_NAME"])."/";

/* Program running path, currently: --------------------------------------------------------------*/
$JOBPATH = getcwd();

POSIX シグナルの処理

/* Register cleaning actions at SIGINT ------------------------------------- */
function shutdown() {
  // Perform actions at ctrl+c 
  echo "Good bye!";
  exit;
}
/* Register resize at SIGWINCH ---------------------------------------------- */
function consoleResize() {
  @ob_start;
  $W = (int)exec("tput cols");   // Columns count
  $H = (int)exec("tput lines");  // Lines count
  @ob_end_clean();
  // Shell window terminal resized!
}

/* Register action at SIGSTOP (Ctrl + z) ---------------------------------------------- */
function sigSTOP() {
  // Program paused!
}

/* Register action at SIGCONT (Type fg to resume) ---------------------------------------------- */
function sigCONT() {
  // Program restarted!
}

register_shutdown_function("shutdown");
declare(ticks = 1);
pcntl_signal(SIGINT, "shutdown");
pcntl_signal(SIGWINCH, "consoleResize");

これは、すべてを 1 つのブロックに書き込む必要があるという意味ではありませんが、レンダリングを 1 つのファイルにマージすると、UNIX 環境で多くの追加機能が可能になります。

言いたいことはたくさんありますが、cli スクリプトとしての php は驚くべき獣です。

于 2020-05-15T17:16:10.070 に答える
0

コードのテストと保守を忘れないでください。単体テストを単一ファイルのプロジェクトに書き込むことができるかどうかは想像できません。さらに、行ったばかりの変更によってどの機能が壊れる可能性があるかを予測することは非常に困難です。モジュールアーキテクチャの場合、モジュールを変更すると、このモジュールとそれに依存するモジュールのみを壊すことができます。小さな変更でも、単一ファイルのプロジェクトでは致命的となる可能性があります (引用符を閉じるのを忘れると、すべてのページが一度に破損する可能性があります)。私たちが行った小さな変更であっても、すべての機能を再テストする必要があると思います。そして、これは、ユニットテストを使用できないテスターに​​とって特に苦痛になる可能性があります。

また、すべてのコードを 1 つのファイルに保存すると、コードが正しくない可能性が高くなります。このようなコードでは、グローバル変数を使用する傾向があります。この場合、そのようなコードを他のプロジェクトで再利用することは困難です。もちろん、それをコピーすることはできますが、何かをコピーすると、そのすべてのバグがコピーされることを忘れないでください。十分にテストされた（ユニットテストのおかげで）ライブラリのセットを使用できるプロジェクトを想像してみてください。新しいバグが発生すると、1 か所で修正されます。

もう 1 つ、チームで 1 つのファイルを使用して作業しているときは大変です。開発者が 2 人しかいない場合でも、変更をマージするのに多くの時間を浪費します。

いずれにせよ、プロジェクトがまったく大きくない場合は、単一ファイル appoch を使用できます。

于 2009-10-13T21:42:32.177 に答える