I gather a bunch of fields into a class object from a web service. I also have many, but not all of these fields included in a table in a database. There are also fields from the database that will not come back from the web service. I’d like to have a SaveToDB method on the class, possibly others and properties that reference related data.
Is there a better way to model this rather than creating two classes for this situation (one for the web service data that comes in and one for when I need to save that data to the database)? Many of the same fields would be repeated on both classes, but is this proper way to go?
I hold to the theory that duplication is the bane of maintainable code. I don’t quite understand your model but I would answer no to two separate classes. If at all possible, structure your code to use only one class. It would be perfectly acceptable to input standard values for those values you do not receive from the web
Would this be a situation to implement a class interface? For example, when a customer record is received from the web service, it comes in with an external key, but my local database uses a different internal key. There are different things I need to do based on whether or not I load this class using the external or internal key.
For example, there are fields I have on the internal customer table that do not come in from the external web service. If I’m loading the class from the external source, I need to populate properties on this class with the existing internal data that does not come back with the external web service. This way when I perform an update to the customer record internally, those properties will not be empty.
Perhaps you might want a class to handle the customer data more generically and then have that class used by two other classes that handle the specific details for how that data is saved/transferred.