2

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

具体的: SQL データベース用の databaseFacade があり、複数のデータベースを非常に簡単に追加できるように、より一般的なものにする必要があります。この場合、CSV ファイルに書き込みます。

データベース層での私のアイデアは、すべてのメソッドが定義されているインターフェイスを作成することでした。次に、このインターフェイスを実装するデータベース ファサード (どちらを使用するかによって異なります) を用意して、より一般的なものにします。次に、ある種の DBmanager クラスがあります。この DBmanager クラスは構成ファイルを読み取るので、どのデータベースを使用するかがわかります。この情報に基づいて、彼はインターフェイスのインスタンスを作成し、これをアプリケーション層に返します。

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

これの正しさについて何か考えはありますか？疑問を持っているからです。

4

3 に答える 3

1

これが正しいアプローチです。些細な疑問の 1 つは、DBManager が実際にはFactoryパターンに従っているため、ファサード クラスが DatabaseFacade と呼ばれると仮定すると、DatabaseFacadeFactory と呼ばれる必要があるということです。

Java に慣れたら、Springを調べてください。このような状況を自動的に処理し、ボイラープレート コードの多くを不要にする多くのツールとテクニックを提供します。詳細については、依存性注入を参照してください。

于 2012-03-17T12:34:58.723 に答える
1

PHP システム ( Moodle ) がほぼ正確にこのパターンを使用し、正常に動作するのを見てきました。DB タイプが構成変数として指定され、具体的な DB アクセス クラスがグローバル DB マネージャー オブジェクトとしてインスタンス化され、行オブジェクトの標準化された配列を返す get_records() などのファサード メソッドが提供されるだけです。これをファサードと呼ぶかアダプターと呼ぶかは議論の余地がありますが、それはほとんど心配する必要はありません。

今のプランでいいと思います。レイヤーを適切に分離し、パターンの目的を理解したようです。また、低レベル (DB) コンポーネントと高レベル (アプリケーション コントローラー) コンポーネントの両方が、中間にある単一の DB ファサード インターフェイスに依存する方法は、依存関係の逆転の良い例です。そのためのボーナス ポイントです! :)

于 2012-03-17T12:22:35.880 に答える
0

私には、それは合法に思えます。私はまだソフトウェア アーキテクチャの専門家ではありませんが、あなたの説明は、JDBC の設計方法と比較して同様の概念を説明しています。

于 2012-03-17T12:09:59.600 に答える