Hi David,
My
personal choice was to use a ValueObject to represent a record from the database. The fields within the ValueObject could then be referenced as the original field type (
String) or as my interpreted field type. My reasoning was that if the field type definition changed at the database level, I would only need to change how to construct my ValueObject using that new field type - the classes which
used the value object would still use the same getters.
I constructed my ValueObjects in the model of my MVC, mainly because of my belief that the instructions require the business logic to be client side (I can point you to a huge discussion on that if you are interested). Similar logic to why I am used a ValueObject in the first place: if the method of connecting to the database / getting the raw data changed, I would only need to change the model of the MVC (which is one of the common reasons for using an MVC).
I have seen other candidates returning ValueObjects from business methods in their servers. If you are already doing conversions from String to some other data format within the ValueObject constructor, then if the database field format changes, you only need to change the constructor to handle the new field format.
Regards, Andrew