実装の詳細がコードの現在のスコープで利用できない場合は、インターフェイスを使用する必要があります。
実装の詳細の一部が入手できる場合は、要約を使用する必要があります。
クエリ - これらの用語が必要な理由は? ビジネス オブジェクトが DataAccess.SqlServer Layer と直接通信できないのはなぜですか?
実装の詳細がコードの現在のスコープで利用できない場合は、インターフェイスを使用する必要があります。
あまり。あなたが言及しているのはカプセル化です。「情報の専門家」という概念があります。何かを行う方法を知っているクラスだけがそれを行うべきです。インターフェイスは、ポリモーフィズムとデカップリングに使用されます。コンシューム コードで特定のタイプのオブジェクトを同じ方法で処理する必要がある場合、そのコードはそれらのオブジェクトをインターフェイス タイプとして処理することで、それらすべてのオブジェクトを同じ方法で使用できます。
実装の詳細の一部が利用可能な場合は、要約を使用する必要があります。
ここで何を意味するのかわかりません。これは正しく聞こえないので、混乱していると思います。抽象クラスは、実装が許可されていることを除いて、インターフェースと同じように使用されます。
クエリ - これらの用語が必要な理由は? ビジネス オブジェクトが DataAccess.SqlServer Layer と直接通信できないのはなぜですか?
それらは可能ですが、保守性、柔軟性、およびテスト容易性が犠牲になります。データ レイヤーを別のデータ レイヤーに置き換えたい場合は、使用するコードが現在のデータ レイヤーに直接依存しているため、それはできません。ロジックを単体テストしたい場合は、DB にアクセスしないとできません。データベース クラスをインターフェイスの背後に配置すると、単体テストでデータ レイヤーをモックし、データベースにアクセスせずにロジック クラスをテストできます。
非常に短い例
public Foo FooLogic
{
IFooData fooData = DataAccessFactory.GetDataClass<IFooData>();
return fooData.GetFoo();
}
これで、ロジック クラスは特定のデータ クラスに関連付けられなくなりました。ファクトリは、実際の FooData 実装を返すことも、モック データ オブジェクトを返すことも、ロジック クラスのコードに影響を与えることなく新しいデータ アクセス レイヤーを配置することもできます。