I'm not so sure there would be significantly more code.
Unless you wanted to generate your types on the fly.
An orm like entity framework can generate the class for each table you're interested in.
Most apps will be reading that data for some purpose of course and maybe you already have that class.
Generically serialising an object to a string is:
public static string SerializeToString<T>(this T source)
{
XmlSerializer xmlSerializer = new XmlSerializer(source.GetType());
using (StringWriter textWriter = new StringWriter())
{
xmlSerializer.Serialize(textWriter, source);
return textWriter.ToString();
}
}
If you instead wanted to see which property had a different value then.
Entity Framework database first makes reading an entire table's worth of data into a List pretty simple.
GetType obtains a type from an object generically.
Type.GetProperties obtains a list of properties the type has.
You can iterate through them use .GetValue on the property to generically obtain a value which you then .ToString().
Reflection is relatively costly but you can obtain the list of properties just once and re-use it for each record.
Yes, that sounds like it would work. Have you actually tried it? The complications always come in the details. I have done things similar to what you are suggesting before.
The nice thing about the solution I have presented is that if your schema changes, the compare code doesn't change. In the solution you are proposing, there are a number of changes that would need to happen to keep things in sync and to be able to compare the new columns.
In this solution, the api tells me which rows don't match and then it tells me which column doesn't match. That is really nice. I have done quite a bit with reflection and it is slow and can be a bit complicated at times to ensure you have proper type matching. If you get your type matching wrong you end up thinking you are matching when you are not, or not matching when you are.
Anyway, I appreciate your comments.
Ben