StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p><strong>[EDIT: Design note]</strong></p> <p>Ok, from a design perspective I would do xslt on the incoming xml to transform it to a unified format. Also very easy to verify the result xml towards a schema.</p> <p>Using xslt I would stay away from any interface or abstract class, and just have one class implementation in my code, the internal class. It would keep the code base clean, and the xslt's themselves should be pretty short if the data is as simple as you state.</p> <p>Documenting the transformations can easily be done wherever you have your project documentation.</p> <p>If you decide you absolutely want to have one class per xml (or if you perhaps got a .net dll instead of xml from one customer), then I would make the proxy class inherit an interface or abstract class (based off your internal class, and implement the mappings per property as needed in the proxy classes. This way you can cast any class to your base/internal class.</p> <p>But seems to me doing the conversion/mapping in code will make the code design a bit more messy.</p> <p><strong>[Original Answer]</strong></p> <p>If I understand you correctly you want to map a ThirdPartyProduct class over to your own internal class.</p> <p>Initially I am thinking class mapping. Use something like <a href="http://automapper.codeplex.com/" rel="nofollow noreferrer">Automapper</a> and configure up the mappings as you create your xml deserializing proxy's. If you make your deserialization end up with the same property names as your internal class, then there's less config to do for the mapper. Convention over Configuration.</p> <p>I'd like to hear anyones thoughts on going this route.</p> <p>Another approach would be to add a <code>.ToInternalProduct( ThirdPartyClass )</code> in a Converter class. And keep adding more as you add more external classes.</p> <p>The third approach is for XSLT guys. If you love XSLT you could transform the xml into something which can be deserialized into your internal product class.</p> <p>Which one of these three I'd choose would depend on the skills of the programmer, and who will maintain adding new external classes. The XSLT approach would require no recompiling or compiling of code as new formats arrived. That might be an advantage.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload