Howdy
When persisting recors to XML what is the best practice regarding whether a field should be persisted as an Attribute or an Element? I've kind of settled on having my key fields as attributes but is that good practice, bad practice or neither?
Printable View
Howdy
When persisting recors to XML what is the best practice regarding whether a field should be persisted as an Attribute or an Element? I've kind of settled on having my key fields as attributes but is that good practice, bad practice or neither?
I've done it both ways... often, it's like anything else - it depends on what works. There's "purists" in both camps. I'm on the fence. I tend to want to put things in to attributes if it's something like a property of that element. Unless it's longer text or text that may have special characters, in which case I'll use elements.
Having Key items as attributes makes sense, it's data that uniquely identifies the item. I don't know if it's best practice or bad, but I'd say it's probably common practice.
-tg
My rule is that it is an element unless it is an attribute of that element :) like so
Code:<Person>
<Details AreUpToDate="yes">
<PhoneNumber IsActive="No">0871234567</PhoneNumber>
</Details>
</Person>
I take it the attributes are bits in red? Can the attributes value be changed pragmatically without manually editing it?Quote:
Originally Posted by DeanMc
Quote:
Originally Posted by DeanMc
OK - but if you turn that into a class are both PhoneNumber and IsActive properties? or is IsActive a method?
@Nightwalker, of course... In LINQ its very easy to do.
@Merrion, well they would all be properties if they need to be referenced outside the class. The key is which data container to use. Since Phone number contains more than one piece of data it becomes complex and therefore needs to either be a class or structure depending on how complex it it and how you wish to use it.