41

PHPで使用するお気に入りのアプリケーション設計/設計パターンを私と共有してください。私が知りたいことがいくつかあります：

  • フォルダの設計方法
  • PHP アプリケーションでオブジェクト指向を使用する方法
  • CRUD、ページネーション、またはその他の一般的なタスクを処理する標準的な方法はありますか?
  • 繰り返しコードを使用しないようにするにはどうすればよいですか? ライブラリ/共通コードの共有などへのアプローチは何ですか?
  • コードをよりエレガントにする方法は何ですか?

これらのすべてに答える必要はありません。これらのいくつかまたはいくつかに答えると役に立ちます。

私がこれを尋ねている理由は、PHP で反復的で醜いコードを書くことに非常にうんざりしていて、フリーランス プロジェクト用の小さなフレームワークを作りたいと思っているからです。 PHP でのプログラミング作業の 80% を占めるフォームの検証、ページネーション、およびその他のありふれた活動ではなく、

すべての意見を歓迎します！

4

9 に答える 9

71

これには反対票が投じられるかもしれませんが、本当に独自のフレームワークを書きたいのであれば、その経験から多くのことを学ぶことができるので、ぜひ試してみてください。ここで言及されている他のフレームワークは優れており、テスト済みであり、それらを使用して悪い決定を下すことはありませんが、それはあなたの選択です.

フレームワークの作成を開始する前に、他のフレームワーク (構文、ディレクトリ構造、ネーミング スキーマ、設計パターンなど) を調べて、なぜそうしたのか、もしあるとすれば何が違うのかを理解してください。いくつかのチュートリアルを試してコードを試し、いくつかのサンプル アプリを作成してください。それを行った後、それらを使用したくない場合は、先に進んでフレームワークの計画を開始し、機能したものを維持し、機能しなかったものを改善します.

自分でロールすることに決めた場合は、私自身の経験からお勧めするいくつかのことを次に示します。

  • セキュリティを最優先事項にする - データ アクセス レイヤーを作成する場合は、バインドされたパラメーターを使用します。フォーム クラスを作成する場合は、CSRF と XSS に注意してください。例外をキャッチし、エラーを処理します。PHP 環境が安全であることを確認してください。独自の暗号化アルゴリズムを考え出そうとしないでください。セキュリティに専念しなければ、独自のフレームワークを作成する価値はありません。
  • コードにコメントする- しばらくするとコードがどのように機能するかを思い出すのに役立つコメントが必要になります。通常、docblock コメントで十分だと思います。その上で、何をしたかではなく、なぜ何かをしたかについてコメントしてください。何を説明する必要がある場合は、リファクタリングすることをお勧めします。
  • 単一の責任クラスとメソッド- ほとんどのクラスとメソッドは、1 つのことだけを実行する必要があります。特にデータベースではこれに注意してください - ページネーション クラスはデータ アクセス オブジェクトに依存すべきではなく、他のほとんどの (低レベル) クラスにも依存すべきではありません。
  • 単体テスト- 各メソッドが 1 つのことだけを行う場合は、テストがはるかに簡単になり、より良いコードが得られます。最初にテストを書き、次にテストに合格するコードを書きます。これにより、何かを壊すことなく後でリファクタリングする自由度が高まります。
  • 類似クラスの抽象化- 類似したことを行うクラスが複数ある場合は、クラス間の類似性を使用する親クラスを作成し、それを拡張します。
  • デリゲートとモジュール化- 検証システムを作成している場合 (そしておそらくそうする可能性があります)、各バリデーターをスーパー検証クラスのメソッドとして含めないでください。それらを個々のクラスに分け、必要に応じて呼び出します。これは、フィルタ、言語、アルゴリズム、バリデータなど、多くの分野で適用できます。
  • 保護とプライベート化- ほとんどの場合、クラス変数への直接アクセスを許可するよりも、getter メソッドと setter メソッドを使用する方が適切です。
  • 一貫性のある API - 異なるクラスで同じことを行う render() メソッドと draw() メソッドがある場合は、1 つを選択してすべてのクラスで使用します。同じパラメーターを使用するメソッドでは、パラメーターの順序を同じに保ちます。一貫した API はより簡単な API です。
  • オートロードを覚えておいてください- クラス名は少し不格好で長くなることがありますが、Zend がクラスに名前を付けてディレクトリを編成する方法により、オートロードがはるかに簡単になります。更新: PHP 5.3 以降、名前空間の使用を開始する必要があります。
  • 何もエコーまたは出力しない- 戻り値として渡して、エコーするかどうかをユーザーに決定させます。多くの場合、戻り値を別のメソッドのパラメーターとして使用します。
  • 世界の問題を解決しようとしないでください- まず自分の問題を解決してください。数値、日付、通貨をローカライズするためのクラスなど、機能が今必要でない場合は、作成しないでください。必要になるまで待ちます。
  • 事前に最適化しない- フレームワークを微調整する前に、フレームワークを使用していくつかの単純なアプリケーションを構築します。そうしないと、生産性のないことに多くの時間を費やすことができます。
  • ソース管理を使用する- 傑作を作成するのに数え切れないほどの時間を費やしている場合は、それが失われる危険を冒さないでください。
于 2009-02-24T10:51:36.633 に答える
13

上記のポスターに同意する必要があります。PHP でプログラミングするときにフレームワークを使用していない場合、実際には手を後ろ手に縛られてプログラミングしています。個人的にはCodeIgniterをお勧めします。これは最速のフレームワークであり、習得が非常に簡単で、非常に活発なコミュニティがあります。すべての質問は、フレームワークによって回答されます。

* How your folders are designed

CodeIgniter (またはそのための任意のフレームワーク) は、ロジックをビュー、モデル、およびコントローラーに分離し、それぞれに独自のフォルダーがあります。

* Do you have a standard way of dealing with CRUD, pagination, or any other common tasks?

CI にはページネーション ライブラリがあり、CRUD 呼び出しをオブジェクト指向 (ORM) でラップするための DataMapper などのサードパーティ ライブラリがあります。

* What are ways in which you can make your code more elegant?

モデル、ビュー、およびコントローラーの分離により、非常に洗練されたコードが作成されます。

（私が答えなかった2つの質問は、フレームワークを使用するときにほとんど暗示されています）

于 2009-02-14T06:46:46.160 に答える
9

多くの php 開発者が私と同様の経路をたどっていると思います: 小さなスクリプト -> プロシージャル/インライン コード -> おそらくテンプレートを見て -> OOP -> 次にフレームワーク。PHP 開発者が PHP で「成長」し、現在のバージョンで利用可能な機能に一致するようにデザイン パターンを学習することはよくあることだと思います。

MVC は、現在使用されている一般的なフレームワークで最も頻繁に使用されるデザイン パターンです。CakePHPは私の選択したフレームワークですが、SymphonyとZendも非常に人気があります。いくつか試してみる価値は十分にあり、すぐにどれが最も使いやすいかが明らかになります。

ほとんどのプロジェクト (迅速な開発と移植可能なコードが優先される場合) では Cake を使用しますが、(低スペックのハードウェアで) 高速に実行したい軽量アプリ (最近開発したのはGood Baadでした) には Cake を使用します。 Rasmus Lerdorf のNo Framework PHP MVC フレームワークに関する記事を読むことをお勧めします。

基本的に、美しいコードとベスト デザイン プラクティスを促進する真のオブジェクト指向言語を求める場合、PHP は常に Ruby Python や C# などに負けてしまいます。しかし、PHP にはその強みがあります。たとえば、テンプレート言語 (テンプレート言語は 1 つです) は必要ありません。PHP は非常に高速かつ安価に実行でき、すべてのアプリケーションに対して大規模なフレームワークの重量を必要としません。

MVC のようなデザイン パターンの管理しやすさを取り入れ、それを PHP の長所と組み合わせたデザイン パターンを採用することをお勧めします。

于 2009-02-24T09:48:07.177 に答える
8

壊れた記録のように感じますが、次の 2 つの理由から、いくつかの一般的なフレームワークを確認することをお勧めします。

  1. 使用しないことを選択したとしても、それらのいくつかは非常によく書かれており、非常によく設計されています. 私は特に Zend Framework が好きですが、すぐに戻ってきます。
  2. 車輪の再発明をしている理由を自問してください。ゼロから何かを書くことを正当化するために、背後にいるコミュニティ (選択したフレームワークをここに挿入) よりも、他の誰もが直面しているのと同じ設計上の問題をはるかによく理解していると本当に感じていますか? 最初にいくつかのフレームワークを見て、それらが大きすぎる、学習曲線が多すぎる、またはオーバーヘッドが多すぎると判断したため、独自のフレームワークを開発した一人として言えます。簡単に拡張できる既存のものをそのまま使用できます。

簡単に拡張できるフレームワークの使用について言えば、私は Zend Framework で非常に良い経験をしました。まとまりがありながら疎結合の構造により、既存のコンポーネントをすばやく簡単に拡張できます。フレームワーク全体は、独自のヘルパー クラスとプラグイン クラスを作成して全体的な機能を追加する必要があるという考えに基づいて設計されています。

私は Zend Framework が非常に柔軟であることを発見したので、Zend Framework MVC の一部として単一の Web サイトを実行し、古いくだらないフレームワークと、まだ書き直していない古いくだらないコードの一部を実行しています。実際、書き直し中に、古いフレームワークを使用すると許容できないほど遅く実行されるページが 1 つ見つかったため、その 1 つのページを Zend Framework アーキテクチャで実行するように切り替えました。

いくつかの質問に答えるには、Martin Fowler 著の Patterns of Enterprise Application Architecture を参照することをお勧めします。彼は、アプリケーションでデータベース インタラクション レイヤーを作成する方法など、これらの一般的な問題の多くを解決する方法について、多くの貴重な洞察を提供します。Fowler は、MVC や Front Page Controller などのトピックもカバーしています。

于 2009-02-14T03:38:00.140 に答える
2

Zend FrameworkとDoctrineを使用すると、私のフォルダー構造は通常次のようになります。

root
  app
    config         (db config, routing config, misc config)
    doctrine       (fixtures, migrations, generated stuff, etc)
    lib
    logs
    models         (doctrine models)
    modules        (zend mvc modules)
    bootstrap.php
  docs             (db diagrams, specs, coding standards, various docs)
  pub              (web root)
  tests
  tools            (console tools, i.e. doctrine-cli)
  vendor           (zend and doctrine libraries, preferably as svn-externals)
于 2009-02-24T09:56:18.250 に答える
2

私は、フォルダ レイアウトと OOP (MVC パラダイム) をほぼ定義する Zend Framework を使用しています。たとえば、私が使用するページネーションZend_Paginator(モデル クラスの実装Zend_Paginator_Adapter_Interface) などの一般的なタスクでは、検証にはZend_Validateクラスなどを使用します。そのおかげで、車輪を再発明する代わりに、ビジネス ロジックに完全に集中できます。

于 2009-02-24T09:00:46.620 に答える
2

PHP の方法論のほとんどをここで説明しました。

しかし、最近では、できる限り Django を使用しています。

于 2009-02-14T04:41:00.957 に答える
1

しばらくの間、自分の作品を書くのをいじくりまわしてきましたが、何かに引っかかってしまうため、毎回完全に仕上げることができません。

そして、自分が正しいことをしているかどうかに気付く部分が来ます。

そういうわけで、私は群衆のお気に入りである Zend と一緒に行くことを自分自身で書くことをあきらめました。

私は他の人を見ましたが、Zendはしばらく前から存在しているようで、彼らは自分たちのことを知っています.

MVC は、私が今書いているものすべてを前進させる方法でもあります。

于 2009-02-24T14:21:46.537 に答える