エンドユーザーに表示されるドロップダウンリスト、Webフォーム上のカスタムグリッドがたくさんあります。それぞれがデータベースからDALを介して入力されます。それぞれに個別のクラスを定義しています。ただし、新しい要件ごとに個別のカスタムオブジェクトが生成されるため、クラスの数を減らすことを考えています。
どうすれば番号を減らすことができますか。そのような要件のためのクラスの?データセット、リストなどを使用する必要がありますか?
エンドユーザーに表示されるドロップダウンリスト、Webフォーム上のカスタムグリッドがたくさんあります。それぞれがデータベースからDALを介して入力されます。それぞれに個別のクラスを定義しています。ただし、新しい要件ごとに個別のカスタムオブジェクトが生成されるため、クラスの数を減らすことを考えています。
どうすれば番号を減らすことができますか。そのような要件のためのクラスの?データセット、リストなどを使用する必要がありますか?
これがそれほど重要に聞こえないことを願っていますが、クラスとして追加される各要件が多くの作業として終了する場合は、継承を調べて、それらのクラスの定型/共有コードをクリーンアップすることができます。
一般に、多くの小さなクラス(他のクラスと機能が重複しない)は良いことです。反対の複雑さの問題である「神」クラスは、すべてのコードがより少ないクラスに詰め込まれているため、はるかに深刻です。
「それぞれに定義された個別のクラス」および「そのような要件のクラスの数を減らすにはどうすればよいですか」。
ドロップダウンリストごとに本当に新しいクラスを作成しますか?私の経験から、通常、私はこのクラスを使用してそれを一般化しました:
public class DropDownItem<T>{
public string Display{get;set;}
public T Value{get;set;}
}
しかし、それを使用して行うことができますDictionary<T>
。
ASP.Netでは使用されませんが、WinformおよびWPFデータバインディングでは適切に機能します。Asp.Net固有では、通常の選択オプションで十分にニーズを満たすことができると思います。
ただし、gridviewの場合は、クラスを一般化してより一般的にする必要があります。null許容可能なパラメータのほとんどを持つクラスを宣言します。
例1つのリクエストには10個のパラメータがあり、5個は必須で、他の5個はnull許容です。グリッドAはパラメーター1、2、3、4、5、7、8を表示し、グリッドBはパラメーター1、2、3、4、5、6、9、10を表示します。このようにして、1つのクラスをさらに多くのグリッドで使用できます。
DataSets/DataTableを使用しないでください。DataSetよりも多くのクラスを使用することをお勧めします。DataSetの「COLUMN_NAME」ではなく、強く型付けされているため、DataSetよりも多くのクラスを使用すると保守性が向上します。