Struttura dati / tecniche ideali per la memorizzazione di dati generici dello scheduler in C #

Non penso che sia troppo difficile. Cosa mi manca?

using System;
using System.Collections.Generic;

public class ScheduledPerson {
    public string Name {get; set;}

    public Dictionary<string, Object> Fields {
        get { return _fields; }
        set { _fields = value; }
    }
    private Dictionary<string, Object> _fields = new Dictionary<string, Object>();

    public List<Tuple<DateTime, DateTime>> Events {
        get { return _events; }
        set { _events = value; }
    }
    private List<Tuple<DateTime, DateTime>> _events = new List<Tuple<DateTime, DateTime>>();

    public ScheduledPerson(string name){
        Name = name;
    }
}

Non vedo un buon modo per rendere generiche le nostre classi ScheduledPerson, in quanto sembra che i campi possano essere qualsiasi cosa. Sto memorizzando i valori del campo come oggetti, poiché non vedo nulla che li richieda per essere dinamici. Assicurati solo che tutti i tipi di valori di campo abbiano un'implementazione ToString () ragionevole.

Se vuoi che gli eventi siano un elenco di DateRange o della tua classe Event anziché di Tuple, sentiti libero.

Rimane quindi il compito di scrivere una classe separata per il rendering di ogni ScheduledPerson in una tabella, oltre a trovare tutte le intestazioni da tutti i record ScheduledPerson. Hai a che fare con diecimila persone, vorrai una soluzione migliore che abbia tutte le intestazioni memorizzate, ma per la maggior parte delle applicazioni, non sarà troppo brutto enumerare tutti i Field su tutti i ScheduledPerson per capire le intestazioni.

In generale, non memorizzerei i dati per la tua soluzione in base al modo in cui desideri visualizzarli. Ciò porta a soluzioni molto specifiche che renderanno le cose difficili quando le vostre esigenze cambiano. Vorrei spezzare le cose in termini di entità nella soluzione e quindi creare una serie di query LINQ che genererebbero i dati di visualizzazione quando è il momento di generare il report.

Tutto il codice seguente è strutturale e omettente l'inizializzazione, ecc.

public class Person
{
   public string Name {get;set;}
   public double Height {get;set;}
   public double Weight {get;set;}
}

public class ScheduledEvent
{
   public Person Attendee {get;set;}
   public DateTime EventDate {get;set;}
}

public class Schedule
{
   public DateTime StartDate {get;set; }
   public DateTIme EndDate {get;set;}
   List<Person> Persons {get;set;}
   List<ScheduledEvent> SheduledEvents {get;set;}
}

Ora, in pratica, li memorizzerei in un database di qualche tipo e faccio tutte le query in fase di esecuzione con qualcosa come NHibernate o Entity Framework. Ma per scopi dimostrativi in memoria, le query per produrre le tue linee di tabella sarebbero le seguenti:

class TableRow
{
   string Name { get;set; }
   string Height {get;set; }
   string Weight {get;set; }
   List<string> DatesWithEvents {get; }
}

var columns = List<string>{ "Name", "Height", "Weight", }.Concat(
                schedule.ScheduledEvents
                  .Select(e=> e.EventDate.ToShortDate())
                  .Distinct())
              .ToList();
var rows = new List<TableRow>();

foreach(var p in schedule.Persons) 
{
   var row = new TableRow();
   row.Name = p.Name;
   row.Height = p.Height;
   row.Weight = p.Weight;
   row.DatesWithEvents = schedule.ScheduledEvents
     .Where(e => e.Person == p)
     .Select(e => e.EventDate.ToShortDate()).Distinct().ToList();
   rows.Add(row);
}    

Quindi nel tuo renderer, abbina le colonne per sapere dove incollare la "X" per contrassegnare che la data è piena. Con uno sforzo maggiore, puoi refactoring in una soluzione molto più elegante, ma questa è la base.