一緒に仕事をしている別のプログラマーと議論しています。
データベースの戻りタイプの場合、メモリ使用量やパフォーマンスの大きな違い、またはDataSetsとDataTablesの使用を避け、実装するタイプを優先するその他の短所はありますIEnumerable<T>か...またはその逆
IEnumerable<T>（ ）を実装する型を返す方が好きです。これはList<T>, T[] etc、より軽量で、プロパティにアクセスするときにオブジェクトに強く型付けされ、基になる型などに関するより豊富な情報が得られるためです。データリーダーを手動で使用する場合でも、設定に時間がかかります。
最近DataTablesを使用する唯一の理由は怠惰ですか？
DataTablesは、メモリ要件と、それらの作成/入力に費やされるプロセッサ時間の両方において、リストよりもはるかに重いことは間違いありません。
DataReaderの使用は、DataTablesを使用するよりもかなり高速です（ただし、より冗長です）（DataAdapterを使用してそれらを埋めていると想定しています）。
そうは言っても...これが本当に重要な場所でない限り、どちらの方法でも問題はないでしょう。どちらの方法も十分に高速なので、どちらの場合もより快適な方法を選択してください。（小さなコードで埋めたい場合もあれば、小さなコードで読みたい場合もあります）
私自身、GridViewにバインドしているとき、または同時に複数の結果セットをアクティブにする必要がある場合にのみ、DataTablesを使用する傾向があります。
System.Collectionsクラスを使用するもう1つの利点は、並べ替えと検索のオプションが向上することです。DataTableの並べ替えや検索の方法を変更する合理的な方法がわかりません。コレクションクラスを使用すると、クラスにIComparableまたはIEquatableを実装するだけで、List.SortおよびList.Containsの動作を完全にカスタマイズできます。
また、リストを使用すると、DBNullについて心配する必要はありません。これは、nullを予期していて、DBNullを取得したために、何度も私をつまずかせてしまいました。
また、メソッドとプロパティを使用してコレクションの基になるタイプを拡張できるという事実も気に入っていIEnumerable<T>ます。これにより、実装がはるかにエレガントになり、コードがより保守しやすくなります。たとえば、FullNameプロパティ。クラスが制御できない場合は、拡張メソッドをクラスに追加することもできます。
public class SomeUser
{
public string FirstName { get; set; }
public string LastName { get; set; }
public string FullName { get { return String.Format("{0} {1}", FirstName, LastName); } }
}
DataTablesを直接使用するということは、基盤となるデータソースとそのレイアウト方法に自分自身を結び付けることを意味します。これは保守性の観点からは良くありません。ビューに必要なのがいくつかのオブジェクトのリストだけである場合は、それだけを指定する必要があります。
私はSQLを介して大きなテーブルで見つけました、データテーブルはIEnumerableの代わりにはるかに高速でした。1つのHTMLページに25列の26k行のテーブルをダンプしました。3秒でDatatable、IEnumerableは9秒かかりました。DataTableに投票します。タイプを除いて、すべてのコードは同一でした。