PHP フレームワークの原則_PHP チュートリアル-PHPチュートリアル-php.cn

PHP フレームワークの原則_PHP チュートリアル

WBOY

リリース： 2016-07-13 10:29:00

オリジナル

809 人が閲覧しました

この記事は主にフレームワーク理論について説明しますが、どのようなフレームワークもこの理論から切り離すことはできません。前回のブログでは、HTML と PHP をより適切に分離するために存在する Smarty について説明しました。いわゆる「フレームワーク」とは、記述形式やアクセス方法を統一するための自制行為であり、実際、この声明によれば、私たちは基本的に、多かれ少なかれ、自分で定義したフレームワークを使用してきました。たとえば、フレームワークを使用していないとき、私は自分でプロジェクトを開発しましたが、混乱を防ぎ、よりよく覚えておくために、ディレクトリとプログラムを計画し、無意識のうちにプログラムを分類しました。たとえば、同じようなプロジェクトをもう一度引き継いだ場合、答えは間違いなく、コードを書き直すことになります。他の人のプロジェクトであり、それを使用して変更しても、実際には同じです。この CMS のルールが何であるかがわからないため、たとえプロジェクトが長く続いても、それは非常に苦痛です。固定の仕様がなければ、毎回作成するコードがどのようなものであれ、特定の標準に従うようにするにはどうすればよいでしょうか。将来書くプロジェクトも、これに基づいて書くことができ、そうすれば独自のフレームワークが生まれます。

しかし、フレームワークだけでは不完全なので、フレームワークにはどのような機能があればよいのでしょうか? それを言うのではなく、私たちが普段書いているコードが確実に何をするのか、Path の問題を減らすためには何を最初に解決する必要があるのかを考えたほうがよいでしょうか。、ディレクトリ構造の配置は実際には非常に重要です。ファイルを含めた後に移動するのは常に面倒ですが、同時に E:www のようなファイルがあります。という質問ですが、この値は事前定義変数 $_SERVER["DOCUMENT_ROOT"] を通じて取得でき、定数として定義できます。define("ROOT_PATH", $_SERVER["DOCUMENT_ROOT"]);include ROOT_PATH"/lib/ mysql.php"; このようにフォルダを移動させても問題ありません。そこで決まった書き方があります。この書き方はパスの問題を解決するために存在します。ほぼすべてのページで使われていますが、出力、データベース接続、これらのコードをカプセル化するか、それらを各ページに含めることができます。なぜこれらを含めると、スマートなテンプレートになるのでしょうか。インスタンス化されたオブジェクトである必要があり、数量名は修正されています (おそらく $smarty)。そのようなファイルをインクルードすると、この数量を割り当てて再度使用することはできません。そのため、コードの次の部分は使用できません。データクラス、アップロードクラス、イメージクラス、ページングクラス、および場所は、コードを変更しないためにこのディレクトリに存在する必要があります。ディレクトリ形式は固定されています。これがフレームを形成します。

長年にわたるプログラマの概要交換と開発経験に基づいて、最も古典的なものはシングルポイントエントリです。以前は、ほぼすべてのプログラムで使用されているいくつかのメソッドをまとめました。たとえば、パブリックファイルを各フォルダーの下に置くと、コードの重複の問題が発生します。ある日、それをすべて変更する必要があり、複数のプログラムに 1 つのプログラムが含まれており、ユーザーは各機能を完了するために n 個のプログラムにアクセスする必要があるため、プログラマーは使用できるかどうか疑問に思います。これらの異なる機能を 1 つのプログラムに含めるには、ユーザーはこのプログラムにアクセスするだけで十分なので、各プログラムが使用する部分を Web サイトのトップページの Index.php に記述し、判断します。取得量などの現在の実際の値を実行するプログラムです。これは、Index.php にインクルードされて実行されます。すべての機能を完了する方法はシングルポイントオブエントリと呼ばれ、このエントリプログラムとそれに対応するディレクトリ構造がフレームワークになります。

セキュリティ上の理由から、ファイルを含める際にディレクトリが修正されることが多く、そうでないと脆弱性が発生しやすいため、パスの先頭と末尾に制限が追加されることがよくあります。たとえば

リーリー

そうすると、パスは、実際には /app/news/list.php が含まれる、index.php?url=news/list のように書くことしかできません。もちろん、実際の状況では、プログラムファイルが存在するかどうかも確認する必要があります。か否か。。

完整一点的话。我们可以这样写这个入口文件。

<?<span>php

</span><span>//</span><span>这里写绝对路径

//这里写数据库连接

//这里写模板初始化，配置

//这里判断连接变量

//这里包含文件进来运行

//这里输出模板

//这里关闭数据库</span>
?>

ログイン後にコピー

一个面向过程的单点入口框架就完成了，是不是有觉得每次都在地址栏带一个 get 不方便？那我们可以换一个写法，例如 tp 框架最喜欢用的 http://localhost/index.php/news/list后面的 /news/list 由程序转成 php 路径包含进来就可以了。在 Apache 环境中，这个 /news/list 可以由服务器变量的 PATH_INFO 取得，如果没有的话。也可以用 REQUEST_URI 取得接近的，IIS 下面，有 HTTP_X_REWRITE_URL 可以取得这个值，自从单点入口模式出现之后，而且oop开发模式从php5开始大行其道，各种oop设计的框架让我们眼花缭乱，但是万变不离其宗，依然是什么入口方式，路径结构是什么样的，文件名的命名规则，用什么样的访问方式，可以运行哪个程序。用oop开发的框架，不外乎就是把主程序改写成为了一个类，

例如：

//包含共用文件，实例化各个类啥的
页面->初始化();

//把用户发来的网址转成要包含的路径
页面->处理网扯();

//在这里包含程序运行
页面->运行()

//输出模板
页面->输出()

各种各样的框架只是为我们准备了一个规矩罢了。。在我们的开发累计的过程中，我们常常会把一些常用的类封装成类，例如，数据库类，文件上传类，图片处理类，邮件收发类，远程访问类，各种接口类……这个时候，我们就会希望框架能给我们提供一个好一点调用类的方法，也就是所谓的“扩展性” ，比如 TP 框架的 Db 类。如果不用其自带的类库只用它们的核心框架，其实几个文件就够了。 TP 框架支持三种访问格式。
/news/list
/index.php/news/list
/index.php?m=news&a=list 第一种需要服务器的 urlrewrite 支持，后面两种可以直接用，事实上，Zend 框架也差不多文件的包含方式是。以类的形式包含，执行的其实是：/文件夹/对象/方法，这种做法有优势。因为在同一个功能中，相似的代码很多，封装到同一个类里面，可以更高效的重复使用代码，

<span>比如这样

</span><span>class</span><span> NewsAction {
    </span><span>public</span> <span>function</span><span> head() {
        在这里处理每一页头部
    }

    </span><span>public</span> <span>function</span><span> index() {
        </span><span>$this</span>-><span>head();
        在这里处理这一页
    }

    </span><span>public</span> <span>function</span><span> show() {
        </span><span>$this</span>-><span>head();
        在这里处理这一页
    }</span>

ログイン後にコピー

还可以利用构造函数等，使每一个功能，在刚进来的时候就都做了同一件事情。以上就是简单框架的理论。