PHP MVC フレームワークを自分で設計する (1)

PHP MVC フレームワークを自分で設計する (1) - URL

フレームワークが普及している今日、MVC はもはや神話ではありません。多くのプログラマーがどのフレームワークが良くてどのフレームワークが悪いのかについて議論しているのをよく聞きます。フレームワークには良いも悪いもありません。自分に合ったものが最適であるだけです。。

私は新卒者にインタビューするたびに、どのようなフレームワークを使用したかを尋ね、それらのフレームワークについての理解を話します。経験豊富なプログラマーを面接するとき、自分でフレームワークを書くように求められます。実際、彼にコーディングを依頼する必要はありません。彼がアイデアを持っている限り、それで問題ありません。経験1年のプログラマーがFramework v0.0.1すら開発できないというのは、フレームワークに対する理解がまだ浅いのではないかと感じます。

数日前、@phoenixg は独自の MVC フレームワークを書くと言いました。そして実際、彼はそれについて話しているだけではありません。たった 1 週間で、このフレームワークのプロトタイプが魔法のように github に登場しました。

このブログ投稿の名前は「Do it Yourself

Design? PHP MVC Framework」であるため、この記事にはあまり多くのコーディングは含まれません。この記事に登場するコードスニペットはすべて vim に直接入力されたものです。 , 記事内のコードを使用したい場合は、テストが行われていません。

このチュートリアルに従って、独自の MVC フレームワークを最初から設計します。

私は ZendFramwork と CodeIgniter を使用しましたが、それぞれのフレームワークには独自の長所と短所があります。この記事を書く前に、Symfony、cakephp、MooPHP、doitphp などのコアソースコードを確認しました。次に、フレームワークをどのように設計するかについて説明します。この章では主に URL の設計について説明します。

1.休息

REST が蔓延するこの時代、フレームワークが REST に対応していないと

前衛的なプログラマから軽蔑されるのは間違いないので、このフレームワークも REST に対応している必要があります。

最初のデザイン原則:?

すべてはリソースであり、リソースにはさまざまな表現形式があります。

実際の存在または抽象化に関係なく、すべてのリソースには不変の ID (ID) があり、リソースに対する API 操作によってリソースの ID が変更されるべきではありません。

実際、上記は完全にインターネットの特性に基づいています。

HTML コンテンツをどのように変更しても、URL は変更されません。
リソースは HTML のリンクを通じて接続されます。
取得するたびに、完全な HTML コンテンツを取得できます。

PHP コード? ?

GET?http://justjavac.com/users????????????//?すべてのユーザー??
GET?http://justjavac.com/users/phper???//?ユーザーは phper として識別されました??

2.拡張子

ここでは拡張子とファイルタイプの関係については説明しません。「拡張子は単なる慣例であり、ファイルタイプはファイルヘッダーに記録されます」。

私は通常、拡張子をファイルタイプではなく「規約」として理解しています。 news.html をリクエストするとき、それがサーバー上に存在する news.html ファイルであるかどうかはわかりません。nodejs が人気の今日では、それが js ファイルである可能性もあります。ファイル。しかし、ページがどのように生成されたとしても、明らかなことが 1 つあります。最終的には HTML ドキュメントが得られるということです。

REST では拡張機能を使用する必要はありませんが、女の子の名前の後に .rmvb 拡張子を追加すると、拡張子が非常に大きくなると言われました。したがって、このフレームワークは拡張機能をサポートしますが、拡張機能はリソースではありません。の一部。

それはどういう意味ですか?

引き続き前の例ですが、このリソースはすべてのユーザーに対してどのように表現されるべきでしょうか? url?http://justjavac.com/users? で一意に識別でき、? 拡張子を使用してリソース のさまざまな表現を識別できます。

a.?http://justjavac.com/users? をリクエストすると、フレームワークはテーブル、フォーム、または div 内のデータを返します (以下に示すように)。

b.?http://justjavac.com/user.json?をリクエストすると、json形式のデータが返されます。

JSコード? ?

[??
????{??
??????"名"?:?"ただ"、??
??????"lastName"?:?"javac",??
??????"userName"?:?"@justjavac"??
????}、??
????{??
??????"名"?:?"トム",??
??????"姓"?:?"猫"、??
??????"userName"?:?"@tomcat"??
????}、??
??????……??
]??

c.?http://justjavac.com/user.xml? をリクエストすると、XML 形式のデータが返されます。XML ドキュメントは DTD または XSD で定義できます。

d. すべてのユーザーのリストを管理者に送信するか、印刷したい場合はどうすればよいですか?

直接アクセスできますか?http://justjavac.com/user.xls すると、フレームワークは Excel スプレッドシートを返します。喜んでファイルをダウンロードしたものの、コンピューターに Excel がインストールされていないことがわかった場合は、どうすればよいでしょうか。問題はありません。私たちはまだ http://justjavac.com/user.jpg にアクセスできます。結局のところ、私たちはまだ画像閲覧ツールを持っています。

Google の短縮 URL サービスを使用したことのある学生は、たとえば、私の Web サイト http://justjavac.com の短縮 URL は?http://goo.gl/JMQJ8 であることを知っています。Google もQR コード表現の場合は、最後に .qr を追加するだけです (例:?http://goo.gl/JMQJ8.qr)。

taourl には、たとえば URL?http://taourl.com/7c1ug のアクセス状況を確認したい場合に非常に便利な機能もあります。 ? の場合は、URL の末尾に + 記号を追加するだけです。

つまり、どのような拡張機能が使用されても、形式が異なるだけで同じリソースが返されます 。よく言われるのがデータ+テンプレート=出力です。

延長がない場合はどうなりますか? HTMLドキュメントを返しますか?

http リクエストを受け入れることを忘れないでください。リクエストヘッダーを設定していますか?Accept: application/x-excel?スプレッドシートは引き続き取得できます。

特定のユーザー ?http://justjavac.com/user/justjavac にアクセスする場合でも、?Accept: text/x-vcard を使用できます。意味がわからない場合は、自分で Google で調べてください。

この機能では、アダプターパターンを使用できます。 異なる拡張子に応じて異なるアダプターを選択し、最終的に同じインターフェイスを提供します。もう言うことはありません。

3. 多言語サポート

@TODO?多言語サポート URL 構造設計

4. HTTPを活用する

リクエストに関連するエラーやその他の重要なステータス情報についてはどうですか?

簡単です。HTTP ステータスコードを使用します。 HTTP ステータスコードを使用すると、インターフェイスのエラー/成功ルールを考え出す必要がなく、すでに行われています。

例: 消費者がデータを送信 (POST) する場合?/api/users,

正常に作成されたメッセージを返す必要があります。その場合は、201 ステータスコード (201=作成済み) を送信するだけで済みます。
サーバーが失敗すると、サーバーは 500 (500=内部サーバーエラー) を送信します。
リクエストが中断された場合は 400 を送信します (400=不正なリクエスト)。
おそらく、POST リクエストを受け入れないインターフェイスにデータを送信しようとするため、501 エラー (実行されない) が送信される可能性があります。
または、MySQL サーバーがダウンしている場合、インターフェースは一時的に中断され、503 エラー (サービスが利用不可) が送信されます。

幸いなことに、ステータスコードについて詳しく知りたい場合は、Wikipedia で調べることができます。

HTTP はクライアント側のキャッシュをサポートしています。HTTP 応答で Cache-Control、Expires、Last-Modified の 3 つのヘッダーフィールドを使用することで、ブラウザーにリソースを一定期間キャッシュさせることができます。

REST は、これらのヘッダーを使用して、クライアントに一定期間内にリソースを再度リクエストする必要がないことを伝えることもできます。これにはパフォーマンス上の大きな利点があります。 Expires、Last-Modified、および ETag は、リソースのプロパティを通じて提供できます。これについては、Model レイヤーの設計で詳しく説明します。

5. テストとデバッグ

PHP の柔軟性により、少なくとも Java と比較すると、自動テストや TDD が困難になります。フレームワークでは、デバッグを自由に有効にすることができます。たとえば、私のデザインでは、次の URL パラメーターを追加します。

<code style="font-size: 1em; padding: 0px; color: inherit; border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px; background-color: transparent; border: 0px;">http://justjavac.com/user/justjavac?DEBUG=2</code>

ログイン後にコピー

DEBUG パラメータを追加してデバッグモードを有効にするようにフレームワークに指示します。後続のパラメータ値はデバッグレベルです。同様に、LOG パラメータを追加してログを有効にすることもできます。

この設計のもう 1 つの利点は、構成ファイルを変更する必要がなく、特定のページに対して

をオンまたはオフにすることもできることです。 CI を使用するときは、プログラム内で問題を見つけるたびに、設定ファイルでログレベルを all に設定し、再度ログファイルを見ると、すでに数百行になっています。訪問したすべてのページがログに記録されます。テストは URL とはあまり関係がないようです。テストについては別の章で説明します。テスト用に同意した URL は、test を追加することです。たとえば、コントローラー justjavac.controller.php 用に書かれたテストケース (Test Case) には、

? を通じてアクセスできます。

http://justjavac.com/test/user/justjavacしかし、私はやはりコマンドラインでテストすることを好みます。結局のところ、手動でブラウザをクリックし、手動で URL を入力し、Enter キーを押すと、

自動テスト

に違反することになります。