抽象DAL-内部クラスでインターフェイスを使用しますか？

データアクセスレイヤー（DAL）と緊密に結合されたビジネスロジックレイヤー（BLL）があります。次のように呼び出します。

using (FooData data = new FooData())
{
  data.DoSomething();
}

internalBLLだけがDALにアクセスできるように、すべてのデータクラスはであり、それらはロジッククラスと同じアセンブリにあることに注意することが重要です。

（ユニットテストを容易にするために）これらを分離するための1つのアイデアは、IFooDataのようなIDataClassインターフェイスを作成することです。インターフェイスを実装するためにデータクラスをパブリックにする必要があるため、最初は問題だと思いました。ただし、メソッドをパブリックにする必要がある場合でも、データクラスを内部に保持できるはずです。

public interface IFooData
{
  void DoSomething();
}

internal class FooData : IFooData  // Notice the class is internal
{
  public void DoSomething();  // Method is public, but that's ok because class is internal
}

したがって、メソッドがパブリックであっても、クラス自体は内部であるため、BLLアクセスのみを許可する必要があります。

このアプローチには本質的に問題がありますか？DALを公開して世界に公開することなく、ユニットテストのためにDALを抽象化するより良い方法はありますか？

インターフェイスを抽出し、BLLがインターフェイスタイプのみを使用していることを確認することは、データベースなしでBLLをテスト可能にするための良い方法です。

あなたがやっていることは絶対に大丈夫です。

を使用してInternalsVisibleToAttribute、DALをビジネスレイヤーから切り離すことができますが、DALメソッドは内部的に保持されます。DALをフレンドアセンブリとして作成することになります。

Assembly.csDALにアクセスできるアセンブリをDALのファイルで指定する必要があるため、これは優れたアプローチではない場合があります。したがって、まだいくつかのカップリングが関係しています（DALはBLLについて知っています）。

だから、あなたの質問に答えるために、あなたのアプローチに何も問題はありません。しかし、フレンドアセンブリを利用すると、より抽象化され、おそらくコードをよりテストしやすくするのに役立ちます。

これがお役に立てば幸いです。

あなたはあなたの質問で説明したあなたの考えに動かないようですが、とにかく私は答えを提出します-誰かが将来いつかそれが役に立つと思うかもしれません。

DALを内部に維持することを主張しているが、それでもいくつかの単体テストを実行して、Microsoft単体テストツールを使用することを気にしない場合は、PrivateObjectアプローチを試してください。これはリフレクションのラッパーであり、常に自分でコーディングできますが、数行のタイピングを節約できます。

InternalsVisibleToを使用することは実行可能なアプローチですが、それは扱いにくいことに注意してください。使用している場合は、すでに高速の下り坂にいる可能性があります。internal何かがそのアセンブリの境界内でのみ公開されていることを意味します。その修飾子は通常、外部から使用できるものを望まないために使用されますそのアセンブリの場合は、すぐに向きを変え、InternalsVisibleToを宣言することでその概念に違反します。これは、リファクタリングのために叫んでいる大きな汚れた赤い旗です。デカップリングは、一方のアセンブリだけがもう一方のアセンブリを呼び出している場合の時間の無駄です。それらを一緒に接着することもできます。デカップリングは、複数のアセンブリがターゲットを呼び出していると推測します（ユニットテストの導入は、すでに述べたようにターゲットアセンブリに到達する方法があるため、「複数」にはカウントされません）。

技術的には、デザインに問題はありません。

ただし、別のアプローチを検討します。BLLをDALから分離する代わりに、DALをデータベースからより適切に分離します。メモリ内でのDALオブジェクトの作成を許可します。BLLがどこかからDALオブジェクトをロードする必要がある場合は、リポジトリパターン（ここを参照）を使用して、BLLがデータベースに直接接続しないようにします。そうすれば、

• データベースを必要とせずに、DALオブジェクトの単体テストを簡単に作成する
• テストデータとしてモックリポジトリを通じて、メモリ内に作成さDALのオブジェクトを提供することにより、あなたのBLLのためのユニットテストを作成します（これらのテストは実際に呼び出される必要がある場合は[OK]を、あなたは今主張できるユニット -testsを）

実際、緩んでいるのは、DALモックでBLLをテストする機能です。しかし実際には、これらのDALモックオブジェクトは通常、実際のDALオブジェクトによく似ており、BLLの有用なテストのベースを提供します。私見では、BLLの自動テストのために実際のDALオブジェクトを再利用するときに、コードの重複と不必要な労力を回避します。

インターフェイスアプローチは、BLLなどのコンシューマーのテスト中にDALをモックアウトするための優れた/主流のアプローチです。

ただし、DAL具象クラスを内部にすると、具象DALを直接テストすることが難しくなる可能性があることに注意してください。これは、バックドアを使用する必要なく、DALユニットテストもこのアセンブリに含める必要があることを意味します。反射のように。

また、将来のある時点で、IoCコンテナーを使用してインターフェースの背後に実装を構築することを検討する可能性があり、これも内部で作動する可能性があります。

BLL /他のレイヤーが具体的な実装ではなくインターフェイスを介してDALに結合する必要がある規則/ LINTルールを追加することで、「内部のみ」で達成しようとしているカプセル化を模倣できます。