WebアプリケーションとN層は興味深いものです。これは主に、JSONとAJAX、またはFlashとXMLRPCの普及によりN層の概念が拡大したためです。Webopediaのこのグラフは、これをうまく表現する青い線をずらして表示しています。要約すると、ビジネス、アクセサ、およびプレゼンテーションロジックは、サーバー上に存在するだけでなく、場合によってはブラウザ内に存在する可能性があります。ただし、N層の目的は分離可能性です。UIやデータベースを変更したり、他のUIを追加したりする必要がある場合でも、ビジネスロジックに影響を与えることはありません。そして、これがAPIを決定するものです。つまり、HTMLとCSSがFlexで破棄され、MySQLがOracleに変更される日を予測しています。
これは決定された要件であり、私が使用した一部のWebアプリケーションでは、N層のバリエーションが同時に使用されます。たとえば、LyrisHQ（電子メールASP）を取り上げます。彼らは顧客のWebアプリケーションを持っています。最近、彼らはFlashベースのアプリケーションをプッシュすることを凝視しています。これは明らかに大量のデータをブラウザに直接送信しており、FlashUIで複製されたビジネスロジックが少しある可能性があります。ただし、異なる（および重複する）要件にはどちらか一方が必要であるため、両方のアプリケーションを維持する必要があります。
最も一般的なPHPアプリケーションは、フォーマットされていないデータをブラウザに送信することを考慮していません。しかし、もしそうなら、これはあなたがあなたのAPIをどのように設計したいかを非常に迅速にあなたに知らせます。おそらく、PHPプレゼンテーションテンプレートが使用したのと同様の内部コントローラークラスに加えて、XMLRPC、REST、またはSOAPと通信できるコントローラーが必要になるでしょう。これは、単純なWebログインページの場合、LoginControllerクラスと通信するログインフォーム用のPHPテンプレートがあることを厳密に意味します。XMLインターフェースも同様に同じLoginControllerクラスを使用します。SQLをAjaxリクエストに書き込むのが面倒だと思うのと同じように、プレゼンテーションテンプレートにクエリを書き込むことは厳密に避けます。
多くの場合、データベースのバックエンドのブランドを切り替える必要がないため、ビジネスレイヤーは多かれ少なかれ厳密になる可能性があります。厳密なN層設計では、ビジネスオブジェクトがデータベースと通信する方法は、ビジネス層を書き直さずにMySQLからMSSQLに切り替えることができるかのようになります。これは、各テーブル（Table Gateway）、各行（アクティブレコード）、各結合、または各トランザクションのオブジェクトをモデル化することによって行われる場合があります。これは、PDOやPHP-ADOのようなものが役立つが、完全に分離するには不十分な場合です。HibernateのようなJavaのORM/Persistenceレイヤーは、多くの場合、オブジェクトクエリ言語（OQL）を提供することにより、この種の分離をより適切に示します。
私自身、現在、MySQLベースのPHPアプリケーションからMS-SQLアプリケーションへのバックエンド移行に取り組んでいます。アプリケーションはこれまで直接SQLクエリのみを使用していました。クラスで一連のクエリを取得する方法を選択し、それらを抽象化するか、サブクラス化するか、できればビジネスロジックを変更しないことを想像してみてください。少なくとも、すべてのSQL呼び出しを間接的に行う必要があります。（PHP ORMに投稿してください。）
そして最後に、OOPについての質問に対して、要件を満たすためにどのように使用する必要があるかを使用してください。私の個人的なテクニックは、PHPプレゼンテーションテンプレートのロジックから数分間始めてボールを転がすことです。すぐにそれをクラスとテンプレートにリファクタリングします。共通の考えがある場合は、ルーチンを共有クラスに分割し、DNRYの原則を維持するよう努めます。（ここでのSO投稿。OOPはN層設計の基本的な要件ではありません。DNRYはコードを保守可能に保つために非常に重要です。多くの場合、期限とスコープシフトによってAPIが破壊されます。必要なものが得られるまでリファクタリングしてください。 OOPがあなたをそこに導くのに役立つに違いない。