2

私はこのようなモデルを持っています

interface IStudent {
   string Name;
   List<Subjects> Marks;
   int RollNumber;
}

class ViewModel {
   ObservableCollection<IStudent> FromExcel;  
   ObservableCollection<IStudent> FromDB;
}

UIで両方のコレクションの結合をバインドする必要があります。最善の方法は何ですか。ObservableCollection<IStudent> FromBoth;比較機能を備えたLINQUnionメソッドを使用して別のプロパティを生成することを考えていました。私の質問は

  1. UIにバインドするコレクションが3つあるのは問題ありませんか？注：Excelからのデータを優先して、重複を削除する必要があります。

  2. 場合によっては、ExcelではなくDBからデータを選択する必要があります。

例：fromExcelではname = "hungrymind"、fromDBコレクションではname="hungrymindconcepts"。デフォルトでは、UIのグリッドはhungrymind（Excelの優先順位）を表示する必要がありますが、ユーザーがUIから列（別名プロパティ）のチェックを外すと、その列のデータの優先順位はDBになります。つまり、UIは「hungrymindの概念」を表示する必要があります。

これを達成するためのアプローチはどうあるべきか。私のアプローチは、ユーザーイベントで、コレクション内の各アイテムのFromDBまたはFromExcelからデータを選択し、それをFromBothコレクションのプロパティに割り当てます。100を超える列があるため、リフレクションを使用する必要がありましたが、パフォーマンスが低下しませんか？リフレクションを避ける場合は、列ごとにメソッドを作成する必要があります。パターンやアプローチに関する提案はありますか？

4

2 に答える 2

2

私はこのような問題を解決しました

interface IStudent {
   string Name { get; set; }
   List<Subjects> Marks  { get; set; }
   int RollNumber  { get; set; }
}

class EntityViewModel: IStudent {
   IStudent FromExcel;  
   IStudent FromDB;
   public string Name {
     get { return Choose("Name").Name; }
     set { Choose("Name").Name = value; }
   }
   public string RollNumber{
     get { return Choose("RollNumber").RollNumber; }
     set { Choose("RollNumber").RollNumber = value; }
   }
   internal IStudent Choose(string propertyName){
     if(IsOveridable(propertyName))
        return this.FromExcel;
     else 
        return this.FromDB  
   }
}
class ViewModel{
   ObservableCollection<EntityViewModel> Entities;
}
于 2012-06-09T17:00:13.270 に答える
0

その場合は、たとえば、データの整理に役立つメタモデルを作成してみませんか。

String objectName
String dataType
String defaultName
String displayName
String userSelectedName
boolean isUserOvverride
String viewType  // (i.e. Text Input, Combo Box, Text Area, Radio Button, Multi Line List)
String viewElementTypeId  // (i.e. for Combo Box,Radio Button this refers to user options available and for Text Input or Area it would be null)

上記のアプローチはパフォーマンスを低下させますが、明日登場する可能性のある任意の数のタイプに採用できます。

于 2012-04-23T06:37:37.937 に答える