データアクセスレイヤー:リストの公開<&gt ;:悪い考えですか?
-
03-07-2019 - |
質問
現在、単純なデータアクセスレイヤーをコーディングしていますが、他のレイヤーにどの型を公開するのか迷っていました。
データをリストとして内部的に実装します<>が、必要でない場合はリストタイプをコンシューマに公開しないことについて読んだことを覚えています。
public List<User> GetAllUsers() // non C# users: that means List of User :)
理由を知っていますか(グーグルは助けにならなかった)?そのようなもののために通常何を公開しますか? IList? IEnumerable?
解決
通常、ユーザーが意味のある作業を行うことができる最も強力でないインターフェイスを公開するのが最善です。ユーザーが列挙可能なデータを必要とする場合は、 IEnumerable&lt; User&gt;
を返します。ユーザーがリストを変更できる必要があるためにそれが十分でない場合(注意!はほとんどの場合そうではありません)、 IList&lt; User&gt;
を返します。
/ EDIT:
Joelは彼のコメントで有効な質問をします。ユーザーに最大のパワーを与えるのではなく、なぜ最も強力でないインターフェースを実際に公開するのですか? (言い換え)
この背後にある考え方は、データを返すメソッドは、ユーザーがそのコンテンツを変更することを期待していない可能性があるということです。ユーザーがリストからすべてのデータを削除したとします。もう1つの方法では、eleが不要だった可能性があることを追加で確認する必要があります。
さらに重要なことは、これは戻り値の型を通じて内部実装の一部を公開します。今後 IList
コンテナを使用しないように実装を変更する必要がある場合、問題があります。メソッドコントラクトを変更して、ビルドに重大な変更を加える必要があります。または、データをリストコンテナにコピーする必要があります。
例として、効率的な実装では辞書を使用し、 IList
を実装しない Values
コレクションを返すだけだと想像してください。
他のヒント
間違いなくISomething。インターフェイスを使用すると、カップリングが減少し、データレイヤーの実装の詳細を今後変更しやすくなります。どのインターフェイスが状況に依存します。 IListは優れていますが、ICollection機能が必要な場合や、ReadOnlyの値を指定したい場合があります。
IEnumerableを返す前に慎重に検討する必要があります。基になるコードが&quot; yield&quot;を使用している場合IEnumerableを生成するか、LINQを使用している場合は、使用されているリソースを開いたままにすることになります。
IEnumerableを別のIEnumerableにコピーしてから返してください。 IListを使用することで、これを要件にし、だれも誤ってIEnumerableを返さないようにします。
一方、IListを返すと、呼び出し元は返されたリストを変更できることを意味します。