1

背景/アイデア
私は現在、php の知識を向上させるためだけに小さなフレームワークに取り組んでいます。このフレームワークは、非常にシンプル (オーバーヘッドを最小限に抑える) であり、後の拡張に関して柔軟でなければなりません。

さまざまな意味
より高度なチュートリアル、本格的な PHP 開発者のメモ、さまざまなクラス構造 (シングルトン、シングルトン、依存性注入、JIT、...)、oop、mvc、ルーティング、キャッシングなどを読んだ結果として、さらに多くのことがわかりました。 「適切な方法」（ある場合）をフィルタリングするのは非常に難しいと思います。

多くの人がそこの意見を「最高」と称賛し、それ以外はすべて悪だと言います。私の意見では、正しいとか間違っているということはありません。目標を達成する方法はいくつかあります。

これまでに行ったこと

  • index: ini 設定、定数の定義、ブートストラップの呼び出し (oop ではない)
  • 起動: オートローダー クラス、名前空間 (必要に応じてファイルを含める)
  • 静的クラス: htmlManager、fileHandler、databaseManager、...
  • シングルトン: なし
  • 非静的クラス: コントローラー、モデル、ビュー、ルートなど

これは非常に基本的なことであり、これまでのところそれほど多くは行っていませんが、まずしっかりしたプラットフォームを作成したいと考えています。

質問
プロジェクトをさらに進めたいと思う前に、以下の項目についてあなたの意見を聞きたいです。

  • 小規模または大規模なプロジェクトをどのように編成/構成していますか?
  • コードの単純さ、ロジック、パフォーマンス、可読性、拡張性、および再利用性に関する経験は何ですか?
  • コーディングの「適切な方法」は本当にありますか、それともこれは単なる解釈ですか?
  • すでに廃止されているため、使用してはいけないものはありますか?

聞きたくないこと

  • フレームワークやphpを忘れる
  • 理由を挙げずにこれをしないでください、それをしないでください

私が得るすべての応答に感謝します。

4

2 に答える 2

2

私は現在、php の知識を向上させるためだけに小さなフレームワークに取り組んでいます。このフレームワークは、非常にシンプル (オーバーヘッドを最小限に抑える) であり、後の拡張に関して柔軟である必要があります。

頑張れ。

より高度なチュートリアル、真面目な php 開発者のメモ、さまざまなクラス構造 (シングルトン、シングルトン、依存性注入、JIT など)、oop、mvc、ルーティング、キャッシングなどを読んだ結果、さらに多くのことがわかりました。 「適切な方法」（ある場合）をフィルタリングすることは非常に困難です。

なぜある特定の方法で何かを解決しなければならないのか、なぜそれがひどい慣行なのかを理解していない人もいますが、何らかの枠組みで何かを見て、スライスパン以来最高のものだと考えているからです。

意見は異なるかもしれませんが、クリーンなコードと適切な OOP について議論することはできません。適切な OOP では、シングルトンとstatics には場所がありません。また、ほとんどの人が MVC と呼んでいるものは、実際にはパターンに対する間違った見方です (主に、何らかのフレームワークが何らかの方法でそれを行うのを見たことがあるためです)。これは必ずしも悪いことではありませんが、MVCではありません。

多くの人がそこの意見を「最高」と称賛し、それ以外はすべて悪だと言います。私の意見では、正しいとか間違っているということはありません。目標を達成する方法はいくつかあります。

私の意見では、最高ではないすべてがひどいわけではありません。しかし、いくつかのものは悪い習慣です。また、いくつかのパターンは、アプリケーションの保守、デバッグ、およびテストを容易にする方法で定義されています。他のパターンを実装する場合は、私には問題ありませんが、他のパターンの利点が失われます。

一般的に言えば、OOP プログラミングを行うときに使用する最初の経験則は、SOLID 原則に従うことです。

静的クラス: htmlManager、fileHandler、databaseManager、...

これらは適切な OOP にはありません。とりわけ、クラスを緊密に結合するためです。これにより、保守性、可読性、およびテスト容易性が苦痛になります。

シングルトン: なし

良い、彼らはただの空想だからglobal.

小規模または大規模なプロジェクトをどのように編成/構成していますか?

構造としての両方のコードでの関心の分離。MVC、MVP、 [MVVM](Model View ViewModel)のいずれかのパターンが役立ちます。個人的には、MVC パターンが最も気に入っています。他のパターンよりも優れたメリットがあるからです。

コードの単純さ、ロジック、パフォーマンス、可読性、拡張性、再利用性に関する経験は何ですか?

読みやすさとテスト可能性が最も重要です。その直後の SOLID (これも最初のポイント (オーバーラップ) で処理されます)

  1. コーディングの「適切な方法」は本当にありますか、それともこれは単なる解釈ですか?
  2. すでに廃止されているため、使用してはいけないものはありますか?
  3. パフォーマンス

フレームワークや php のことは忘れてください 理由を挙げずにこれをしないでください、あれをしないでください

前に述べたように、ただそれを実行してください。それをして、それを台無しにしてください！学ぶための最良の方法は、実際にそれを行い、ひどい間違いを犯すことです. 私が 1 年前に作成したフレームワークは (実際に出回っているフレームワークの 90% よりも優れていますが) 適切ながらくた ™ だと思います。

于 2013-01-25T13:30:34.040 に答える
0

小規模または大規模なプロジェクトをどのように編成/構成していますか?

多くの PHP フレームワークは MVC 構造を使用します。

コードの単純さ、ロジック、パフォーマンス、可読性、拡張性、再利用性に関する経験は何ですか?

MVC に厳密に従うことに加えて、KISS や DRY などの原則に従うことをお勧めします。私は、パフォーマンスを優先度の高いトピックとは考えていません。後でキャッシュ戦略と優れたアルゴリズムに慣れることができます (PHP ではなく一般的なトピック)。

コーディングの「適切な方法」は本当にありますか、それともこれは単なる解釈ですか?

Zendやsymfonyなどの一般的なフレームワークに関する多くのヒントを見つけることができます。

すでに廃止されているため、使用してはいけないものはありますか?

自分で調べる必要があります。データベース処理の記述をスキップして、doctrine や propr などの ORM ライブラリを使用できます。twig や smarty などのビュー表現用の特別なテンプレート エンジンを選択できます。

理由を挙げずにこれをしないでください、それをしないでください

長年の PHP プログラマーは全員、少なくとも 1 回は独自のフレームワークを開始したことがあると思います。特に知識を向上させたい場合は、それに対する議論はありません。

于 2013-01-25T12:51:58.243 に答える