2009-10-28 24 views
8

私の質問は、インターフェイスの使用についてではなく、プロジェクト組織の性質の詳細です。インターフェイスは実装とは別のプロジェクトにする必要がありますか?

注:私は、VisualStudioを多層アプリケーションで使用しています。

私のインターフェイスファイルは、実装とは別のプロジェクトに存在する必要がありますか?私の最初の考えは、私のサービスインターフェイスを自分のプロジェクト(私の最初の実装のためのプロジェクト)に分けて、実装/コンクリートプロジェクトを削除して新しいものに置き換えることができるようにすることです必要。

例を明確にする:MyApp.Business.Services名前空間に存在するIBusinessServiceというビジネスレイヤーインターフェイスがあるとします。私の実装であるFooBusinessServiceは同じ名前空間に存在しますが、VisualStudioでは異なるプロジェクトになります。後で実装を修正する必要がある場合、開発者はFooService.projへの参照を削除し、BarService.projへの参照で置き換えることができます。

具体的な実装(古くなっているかもしれないし、あなたに役に立たないかもしれない)を取らずに、インターフェースだけを使ってプロジェクトを参照できるようにすることで、アプリの解決策を見逃すようですが、何か不足していますか?

+0

[私はインターフェイスのための別のアセンブリが必要ですか?](http://stackoverflow.com/questions/3363312/should-i-have-a-separate-assembly-for-interfaces) – nawfal

答えて

10

私はあなたと一緒です。私は別のプロジェクトと別の名前空間に私のインターフェイスを置くことを好む。古典的な例は、データアクセスクラスです。同じインターフェースを実装しているMSSQLバージョンとMySQLバージョンをコーディングできるようにしたいとします。したがって、私はインターフェイス定義を別のアセンブリ/プロジェクトにすることをお勧めします。ここで私はアセンブリと名前空間をレイアウトする方法の例です:

  • Elder.DataAccess.Core - インタフェースの特定のMSSQL実装
  • エルダー - インタフェースおよび一般的なユーティリティ
  • Elder.DataAccess.MSSQLが含まれています。 DataAccess.MySQL固有のMySQLインプリメンテーション

これにより、インターフェイス定義を含むプロジェクトに触れることなく、実装を変更できます。これは、バージョン管理と変更の追跡にも役立ちます。この猫には他の方法で肌をかぶるかもしれないので、私は他の人の答えを見たいと思っています。

+1

Scottさん、ありがとうございます。これは私が今使っている構造です。ちょうどそれが意味をなさないという確証と私が何かを逃していないことを望んでいました。他の誰かが欠陥を指摘していない限り、私は自分のインターフェースにこれを使うつもりです。 –

関連する問題