Classe extra per scrivere dati su qualche back-end?

Prenderò in considerazione la modellazione del formato di output come classe separata. In altre parole, vai con la tua idea ExcelDocument . Ciò si presta bene a qualcosa di simile al modello di strategia se è necessario supportare più formati di back-end, ora o in futuro .

Avresti un'interfaccia che definisce le operazioni che esegui sull'archivio dati, come la lettura e la scrittura. Quindi si implementa quell'interfaccia in un certo numero di sottoclassi, ciascuna progettata per gestire un tipo specifico di back-end, come file CSV, file Excel XLS, database SQL insetto-qui-qui. Se hai solo un output adesso, non hai necessariamente bisogno dell'interfaccia, ma se sei sicuro che aggiungerai altri formati in futuro, prenditi cura della gerarchia delle classi ora.

Ovviamente, dipende da quanto siano complesse queste azioni. Potresti preferire la scomposizione in entrambe le classi "lettore" e "scrittore" invece di mettere tutto in uno. Questo potrebbe anche essere più in linea con Principio di responsabilità singola .

Puoi affrontare questo problema con una mentalità di dipendenza delle dipendenze: la tabella dovrebbe esporre un'interfaccia necessaria per scrivere se stessa in un archivio persistente.

Potresti passare questo nel costruttore di tabelle:

Table(ITableWriter tableWriter)
{
    _tableWriter = tableWriter;
}

E quindi Table implementa qualcosa come:

void Write(string writeID)
{
    //for all rows in the table
    _tableWriter.Write(writeID, rowToWrite);
}

Quindi le tue chiamate potrebbero essere:

var excelWriter = new ExcelWriter(); // implements ITableWriter
var table = new Table(excelWriter);
table.Write("DocumentName");

Il trucco è quindi definire la classe ExcelWriter che implementa l'interfaccia ITableWriter , con il deliverable che è un documento Excel.

In questo modo, se dovessi scrivere la tabella da qualche altra parte (in un altro database? in un file flat?) non dovrai modificare la classe Table, ma solo produrre un'altra implementazione dell'interfaccia ITableWriter .

Come bonus aggiuntivo, puoi prendere in giro l'interfaccia ITableWriter per test separati della tua classe Table .

Hai ragione, quelle classi dovrebbero servire a un unico scopo in quanto rappresentano il tuo modello . Dovresti scrivere una classe servizio che trasformi una di queste classi nell'altra quando necessario.

Strutturalmente, le classi di servizio e le classi di modelli sono le stesse, ma sono lì per definire le preoccupazioni separate dei diversi livelli di un'implementazione MVC, per esempio. Una classe di servizio concreta definisce l'API di un servizio esterno, come la trasformazione di una tabella di dati in un foglio di calcolo Excel e una classe di modello definisce l'API del modello di dati dell'applicazione.

Quindi, mentre le classi base possono essere simili, le classi concrete create estendendo queste classi base servono due scopi completamente diversi.