Currently, there is just one model used throughout the whole extension: the CsvEntry.
This model, however, is tightly coupled with the storage format.
Problem
One model does not fit all. For instance, the location information is stored as a string in this model. But this is a choice only reasonable for the csv export, but not at other places in the program, where having explicit access to, say, the stating line would be needed.
Solution
Introduce a program internal data model.
Also: Consider applying the Repository Pattern to reduce the coupling to the explicit Csv output format. This would also make switching to future output formats (json? yaml?) easier.
Situation
Currently, there is just one model used throughout the whole extension: the
CsvEntry. This model, however, is tightly coupled with the storage format.Problem
One model does not fit all. For instance, the location information is stored as a string in this model. But this is a choice only reasonable for the csv export, but not at other places in the program, where having explicit access to, say, the stating line would be needed.
Solution
Introduce a program internal data model. Also: Consider applying the Repository Pattern to reduce the coupling to the explicit Csv output format. This would also make switching to future output formats (json? yaml?) easier.