3層アーキテクチャの正確さ

Question

私は（欠陥のある）3層アーキテクチャで実装されたプロジェクトを持っています。私の仕事は、プロジェクトに新しいデータベースを追加するのが簡単になるように、より一般的なものにしています。

具体的には、SQLデータベースのdatabaseFacadeがあります。私は複数のデータベースを非常に簡単に追加できるように、より汎用的にする必要があります。この場合は、CSVファイルに書き込んでください。

データベースレイヤーで私の考えは、すべてのメソッドが定義されたインターフェイスを作ることでした。その後、データベースをファサード（あなたが使いたいものに応じて）にして、このインターフェースを実装して、より一般的になります。 それからDBmanagerクラスがあります。このDBmanagerクラスは、使用するデータベースが分かるように設定ファイルを読み込みます。この情報に基づいて、彼はインターフェイスのインスタンスを作成し、これをアプリケーションレイヤに返します。

しかし、これは私が正しいかどうかわからないところです。アプリケーション層にはDBmanagerクラスがあります（ここではすべてが正しくカプセル化されていますが、ファサードを返すためには1つのメソッドしかパブリックではありません）。その後はDBfacadeです。

この正しさについてのご意見はありますか？私は疑問を持っているので。

Answer 1

私には正当だと思われます。私はまだソフトウェアアーキテクチャーの専門家ではありませんが、あなたの説明ではJDBCの設計方法と似た概念が説明されています。

Answer 2

私はPHPシステム（Moodle）がほぼ完全にこのパターンを使用しているのを見てきました。起こるのは、DB型が構成変数として指定され、具象DBアクセスクラスがグローバルDBマネージャオブジェクトとしてインスタンス化され、ファサードメソッドを提供することだけである。 get_records（）は、行オブジェクトの標準化された配列を返します。あなたがこのファサードかアダプターと呼ぶかどうかは疑問ですが、それはほとんど心配ありません。

私はあなたの現在の計画と一緒に行きます。あなたは層を適切に切り離したように見え、パターンの目的を理解しています。また、低レベル（DB）コンポーネントと高レベル（アプリケーションコントローラ）コンポーネントの両方が、真ん中の単一のDBファサードインターフェイスに依存する方法は、dependency inversionの良い例です。そのためのボーナスポイントです！ :)

Answer 3

これは正しいアプローチです。あなたのDBManagerが実際にFactoryパターンに従っているので、ファサードクラスがDatabaseFacadeであると仮定して、DatabaseFacadeFactoryと呼ぶべきです。

Javaの方が快適になれば、Springをご覧ください。これは、このような状況を自動的に処理し、定型コードの多くの必要性を取り除く多くのツールとテクニックを提供します。詳細については、dependency-injectionを参照してください。