トムの答えに対するあなたの反応を踏まえて、Zend Framework のようなものを見ることをお勧めします。その ORM には、段階的に実装できる、取るか放置するかのアーキテクチャがあります。
私が現在の雇用主のところに来たとき、彼らは数か月前に完成したばかりのアプリケーションを持っていましたが、1 つまたは 2 つの以前のバージョンを使用しており、現在のバージョンは想定よりも 6 か月長く開発されていました。ただし、コードベースはめちゃくちゃでした。たとえば、データベース アクセス ロジックとビジネス ロジックの間に抽象化がありませんでした。そして、サイトを前進させて新しい機能を構築し、既存の機能を拡張し、コード内の既存のバグを修正するように求められました。さらに複雑なことに、彼らはデータの入力または出力に対していかなる形式のサニテーションも使用していませんでした。
問題に取り組み始めたとき、明らかに完全に書き直すつもりはないため、段階的に実装できる抽象的懸念に対する解決策が必要であることに気付きました。私の最初のアプローチは、面倒な作業を行うカスタム ORM と DAL を作成することでした。既存のコード ベースに干渉しないため、非常にうまく機能し、目立たない方法でアプリケーションのすべての部分を新しいアーキテクチャに移行できました。
ただし、サイトのユーザー領域の大部分をこの新しい構造に移植し、カスタム フレームワーク (カスタム フロントエンド コントローラーと mvc 実装も含まれるようになりました) でアプリケーション全体を構築した後、切り替えています。 Zend Framework (これは私の選択ですが、他のフレームワークのいくつかもこの状況で機能すると確信しています)。
Zend Framework に切り替えるにあたり、レガシー コード ベースについてまったく心配していません。その理由は次のとおりです。
- 新しいモデルを構築し、(カスタム フレームワークで構築された) 古いモデルをさりげなくリファクタリングできます。
- Zend の MVC フレームワークと一貫性のある方法で動作するクラス内にラップされるように、既存のコントローラー (そのようなもの) をリファクタリングして、Zend のフロントエンド コントローラーを実際に使用し始めることが小さな問題になるようにすることができます。
- 私たちのビューはすでに Smarty に組み込まれているので、コントローラーとビューのロジックを分離することを心配する必要はありませんが、既存のテンプレートを Smarty でレンダリングしながら PHP で新しいテンプレートを構築できるように、Zend Framework を拡張することができます。
基本的に、Zend Framework には、新しいコードやリファクタリングされたコードが既存のコードに侵入する必要がないため、既存のプロジェクト内で使用するのが楽しくなるテイク イット オア リーブ アーキテクチャがあります。