Extra class for writing data to some backend?

Question

What is the common practice to write classes which take some data class and store it to some backend? In my case I have table classes (columns, headers, etc.) which are written to Excel. So I have a class Table with the data and a class ExcelDocument with access operations and basic writing (cells, ...).

Where would I put the code which knows how to deal with Table data and knows how to write that the ExcelDocument? Both might be subject to refactoring at some point.

Do I use Table.write_to_excel(excel) or ExcelDocument.write_table(table) or even some need intermediate class? With the concept "a class should serve just one purpose" I'd most likely write an intermediate class?

Answer 1

I would consider modeling your output format as a separate class. In other words, go with your ExcelDocument idea. This lends itself well to the something like the Strategy pattern if you need to support multiple back end formats, now or in the future.

You would have an interface that defines the operations that you perform on the data store, such as reading and writing. You then implement that interface in a number of subclasses, each designed to handle a specific type of backend, such as CSV files, Excel XLS files, insert-flavor-here SQL database. If you only have one output now, you don't necessarily need the interface, but if you know for sure that you'll be adding more formats in the future, take care of the class hierarchy now.

Of course, it does depend on how complex these actions are. You might favor decomposing into both "reader" and "writer" classes instead of putting everything in one. This might also be more in line with the Single Responsibility Principle.

Answer 2

You can approach this problem with a dependency injection mindset: The table should expose an interface that it requires to write itself to a persistent store.

You could pass this into the Table constructor:

Table(ITableWriter tableWriter)
{
    _tableWriter = tableWriter;
}

And then Table implements something like:

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

Then your calls could be:

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

The trick is then to define the ExcelWriter class that implements the ITableWriter interface, with the deliverable being an Excel document.

That way, should you need to write the table somewhere else (to another database? to a flat file?) you won't have to change the Table class, just produce another implementation of the ITableWriter interface.

As added bonus, you can mock the ITableWriter interface for separate testing of your Table class.

Answer 3

You're right, those classes should serve a single purpose as they represent your model. You should write a service class that transforms one of those classes into the other when necessary.

Structurally, service classes and model classes are the same, but they are there to define the seperate concerns of different tiers of an MVC implementation, for instance. A concrete service class defines the API of an external service, like transforming a data table into an excel spreadsheet, and a model class defines the API of the application's data model.

So, while the base classes may be similar, the concrete classes created by extending these base classes serve two entirely different purposes.