In general, is there any reason not to use a TypeConverter for conversion chores involving custom types that have nothing to do with UI?

Im thinking about ca开发者_C百科ses more complex than implict & explicit conversions.

Any links to design guidelines & samples for doing so?

Cheers,

Berryl

UPDATE

Here is the motivation for the conversion, a Party - PartyRelationship pattern where a Party can have One or many PartyNames. When the Party is a Person, the One required name is a PersonName.

The PersonName has attributes that are different from a PartyName and is a ValueObject. It is used for ui / formatting type tasks whereas the PartyName is an Entity and is persisted to the database.

So conversions are needed: - Load from DB for presentation: (PartyName --> PersonName) - Add new contact to DB: (PersonName --> PartyName)

---

Here's a good link that explains the difference between a TypeConverter and implementing IConvertible. But, basically, TypeConverter is built for, and most useful for, doing type conversions at design time. For example, it's how XAML converts types to XML and back.

IConvertible is generally more flexible, faster (it doesn't use reflection), and easier to implement than a TypeConverter. Unless you need the extra features that TypeConverter gives you (like the list of standard values), I would recommend you go with the interface option and use the Convert static methods.