Currently I'm working on application reading invoice data from SQL Server and I need to export that data to CSV (with certain logic, some fields are constant).
Example logic: CalculateTax, check if PaymentMethod starts with "Cash", "Credit Card" then set byte flag to PaymentMethod field in CSV class etc.
In this case, should I create just one FileHelpers class - for reading data? Then map read fields to more useful class, apply logic and export it in normal way (as said here)? But this would not utilize FileHelpers ability to write to file. Would it be ambiguous to make FileHelpers class for writing?
There are so many ways of reading the data from SQL Server, depending on the volume of records and whether the schema is likely to change, FileHelpers is not necessarily the best solution.
However if you'd like to use FileHelpers for this then certainly check out Ayende's blog post about integrating it with RhinoETL.
But basically, yes, I would use define one FileHelpers class (with only public fields) to read from SQL Server. Then create another FileHelpers class to describe the desired CSV output (again with only public fields). Then create a mapper class which will be responsible for mapping the values from the SQL extraction to the CSV output (along with any necessary logic).