Sto costruendo un'applicazione responsabile della lettura dei dati dai file e della loro visualizzazione nei grafici. L'intera applicazione è responsabile della manipolazione dei dati da file, il che significa che devo utilizzare diverse parti dello stesso oggetto in quasi tutte le parti del mio progetto. I grafici hanno bisogno di dati reali, l'elenco dei file aperti ha bisogno di nomi e stati di dati, ecc. Inoltre, la mia applicazione utilizza MEF , quindi altri possono aggiungere nuove funzionalità e modificare i moduli correnti.

Il mio problema più grande è come separare i dati, in modo che ogni livello della mia applicazione abbia accesso solo a parte dei dati necessari per il loro funzionamento. Quello che intendo per dati è:

1. Nome del file
2. Id guida
3. List<IColumn> dati o byte[] dati
4. Altre variabili future

Ho deciso di utilizzare tutta la mia applicazione IDocument . Questa è la mia rappresentazione personalizzata di un file che può essere letto e visualizzato nel grafico. Ogni IDocument deve avere un Id e Name perché ogni file del computer ha un nome. Questo ha tutte le informazioni necessarie per un semplice elenco di file che sono stati importati nell'applicazione. Ma non ha i dati effettivi che voglio visualizzare, quindi uso il database NoSQL per archiviare IDocumentData che ha List<IColumn> Columns che posso inserire in un grafico. IColumn ha solo List<object> Rows che sostanzialmente riproduce una tabella.

Quindi ho separato il mio file in IDocument e IDocumentData , ora come faccio a tenere traccia di quali dati appartengono a quale documento? Ottengo IDocumentData dal modulo IReader e ottengo IWizardData dal modulo IFileImporterWizard . Stavo pensando di creare un qualche tipo di builder che assegnerebbe lo stesso Id a IDocument e IWizardData (contiene% importato% co_de e Name ) e quando vorrei accedere ai dati vorrei passare Id da% codice%. È un buon approccio?

Quindi ad esempio:

public class DocumentBuilder {

  private IDocumentFactory _documentFactory;
  private IDocumentDataRepository _documentDataRepository;

  public DocumentBuilder(IDocumentFactory documentFactory, IDocumentDataRepository documentDataRepository)
  {
     _documentFactory = documentFactory;
     _documentDataRepository = documentDataRepository;
  }

  public IDocument Build(IWizardData wizardData, IDocumentData documentData) 
  {
      var document = _documentFactory.Create();
      document.Id = wizardData.Id;
      documentData.Id = wizardData.Id;

      _documentDataRepository.Add(documentData);
      return document;
  }
}

Quindi il mio modo di pensare è il seguente: Apri procedura guidata file restituisce Id (nome, filePath) - > IDocument restituisce IWizardData ( IReader colonne) - > IDocumentData build List<IColumn> e salva i dati

Modifica

Quindi ho capito come separare i livelli aziendali e di dati creando

interface IDocument : IDocumentData, IDocumentInformation 

DocumentBuilder ha un nome e altre informazioni. IDocument ha IDocumentInformation e IDocumentData . Posso salvare Id e DataTable Data { get; set; } separatamente e avere ancora IDocumentData uguale per entrambi.

Ho deciso di cambiare IDocumentInformation e Id , perché spero che IColumn causerà meno problemi. Anche se mi chiedo ancora se List<object> Rows sia una buona scelta, perché probabilmente ridurrà le prestazioni durante il caricamento dei dati. Ho pensato che sarebbe una buona idea caricare da DataTable solo un paio di record e poi aggiungerli al grafico e farlo scorrere fino alla fine.

Quindi ora DataTable restituisce NoSQL , IFileWizard prende IDocumentInformation e restituisce IReader e quindi vengono combinati.

Il nome di queste cose richiede un po 'di tempo, perché tutte usano parti dello stesso oggetto, ma vedere IDocumentInformation che restituisce IDocumentData è un po' strano. D'altra parte per renderli facilmente intercambiabili dovrei dichiarare interfacce ancora più comuni e creare IFileWizard e avere IDocumentInformation e quindi restituire interface IFileWizardResult:IInfo e lanciarlo a interface IDocumentInformation:IInfo , ecc. Io non sapere se questo è troppo disaccoppiato o meno. Voglio che questa applicazione sia facilmente scalabile, ma creare molte interfacce non significa sempre un migliore disaccoppiamento.