SelectListItem [] ASP.net mvc以外のUIレベルでの代替

Question

aps.net MVCプロジェクトに含まれていないBL、DALなどのレベルでSelectListItem[]の使用が見られました。

私はIEnumerable<KeyValuePair<string, string>>の代わりに何かを使用する傾向があります。 Dictionary<string,string> c.f. Creating the IEnumerable<KeyValuePair<string, string>> Objects with C#?

私の理由が必要でないときWeb.MVCに余分な依存関係を追加するものではなく、IEnumerable<KeyValuePair<string, string>>

は、これらの正当な理由はありますか1つを考慮しなければならない上にカウンターポイントがあるより重いようSelectListItemは、MVCのコンテキストに属します。

よく知っているプリンシパルがあります。不要な場合に依存関係を減らすための原則はありますか？

Answer 1

インターフェイスへのプログラミングは、より大きなシステムでコンポーネントをデカップリングし、再利用性を向上させるのに役立ちます。

IList<T>の代わりにIEnumerable<T>を返すメソッドシグニチャが表示されたら、あなたの言うことを考えてみてください。

あなたはデザイナーが結果を列挙することを期待していて、結果が変わっても結果を突然変更するつもりはないとあなたは思っています。

新しいコンポーネントまたはライブラリを設計するときは、まずメソッドのどちらかの面で期待される動作について質問します。発信者が実際にint[]を提供する必要がありますか、IEnumerable<int>で手に入れることはできますか？

さらに、配列が必要な場合は、消費者に意見をプッシュしていますか？ "アレイは私がいつもより良いと思いますので、私に配列を渡すべきです。"同時に

メソッドのシグネチャがIDictionary<TKey, TValue>を取る場合、私は私のコードは、新しい（っぽい）不変コレクションのいくつかの恩恵を受けるだろうと判断した場合、私は簡単にImmutableDictionary<TKey, TValue>ためDictionary<TKey, TValue>を入れ替えることができます。

あなたの依存関係を減らすべきかどうかは、あなたのチームがプロジェクト要件に照らして考えることになると思います。しかし、具体的なタイプを、該当する場合には有益なインターフェースに置き換えるという問題については、それを検討してください。