5

次のように分割されたアプリケーションに取り組んでいます（少し簡略化されています）

App
|
Framework
|
Data (Persistance)
|
Data.Couchbase

アプリ内で、DI コンテナーをセットアップし、特定のインターフェイスが必要な場合に使用される具体的な実装を登録します。

つまり、Data 名前空間の IUserRepository は、Data.Couchbase 名前空間の CouchbaseUserRepository によって満たされます。将来、永続レイヤーを別のテクノロジー (Mongo など) に交換すると、DI 登録を更新でき、MongoUserRepository によって実行されます。

万事順調……。

質問1

システムの境界をまたがるインターフェースを提供することには明らかな利点がありますが、 Data.Couchbase 名前空間自体についてはどうでしょう。それ自体が追加の機能を提供しない場合、ICouchbaseUserRepository インターフェイスを持つことに意味はありますか? IUserRepository -> CouchbaseUserRepository を登録すれば十分なはずです。同様に、具体的な実装内では、これらのコンポーネントを、おそらく交換されないインターフェースにさらに分割することに意味があります

質問2

同様に、データ内のインターフェイスにプロキシすることのみを目的とするフレームワークに一連のインターフェイスを用意する価値があるため、アプリはフレームワークのみに依存でき、データにも依存する必要はありません。利点がわかります....実際にはできないかもしれません....フレームワークに何百ものインターフェイスがあり、特にこれらのアセンブリが「データ」に依存する可能性があるようです同じブリキの上で生きていく

乾杯

4

2 に答える 2

1

これらの質問は両方とも、コーディングとデザインスタイルの領域に分類されます。そのため、プログラマーのサイトにより適している可能性があります。（https://softwareengineering.stackexchange.com/）

設計の問題に対処する場合、主要なプラクティスは明確です。DB層を定義するインターフェイスが必要です。そうすれば、新しいタイプのデータアクセスを簡単に注入できます。

（質問で説明しているように）インターフェイスが機能的に必要ない場合、インターフェイスの必要性は明確さを提供することです。これは、システムをより明確にするコーディングスタイルです。

たとえば、連絡先管理システムでは、連絡先を定義するデータベース/システム「オブジェクト」へのインターフェイスを定義することが理にかなっている場合があります。次に、さらに人や組織のためのインターフェースを作成します。これは、このアプリケーションのコンテキストで役立ちます。ドキュメント管理システム用にこのようなインターフェイスを作成しても意味がありません。どちらの場合も、DBインジェクション用にインターフェースを定義する必要があります。

設計者およびプログラマーとしてのあなたが決定しました。システムを設計する際のスタイルの選択に関しては、厳格な規則はありません。

于 2013-03-01T16:05:43.617 に答える
1

答え 1

IUserRepository を実装する CouchbaseUserRepository は非常に理にかなっています。すべてのアプリケーション ロジックはインターフェイスのみを使用するため、後で Mongo に切り替える場合は、MongoUserRepository に同じインターフェイスを実装させるだけで済みます。

答え 2

大規模なアプリケーションを構築している場合は、間違いなく、db レベルとフレームワーク レベルの 2 つのインターフェイス層を使用してください。それほど大きくない場合は、多すぎる可能性があります。どちらの場合も、フレームワーク レベルでインターフェイスを作成することは間違いではありません。

于 2013-03-01T15:59:57.557 に答える