If my domain object should contain string properties in 2 languages, should I create 2 separate properties or create a new type BiLingualString?
For example in plant classification application, the plant domain object can contain Plant.LatName and Plant.EngName.
The number of bi-lingual properties for the whole domain is not big, about 6-8, I need only to support two languages, information should be presented to UI in both languages at the same time. (so this is not locallization). The requirements will not change during development.
It may look like an easy question, but this decision will have impact on validation, persistance, object cloning and many other things.
Negative sides I can think of using new dualString type:
- Validation: If i’m going to use DataAnattations, Enterprise Library validation block, Flued validation this will require more work, object graph validation is harder than simple property validation.
- Persistance: iether NH or EF will require more work with complex properties.
- OOP: more complex object initialization, I will have to initialize this new Type in constructor before I can use it.
- Architecture: converting objects for passing them between layers is harder, auto mapping tools will require more hand work.
If you 100% sure that it will always be only Latin and English I would just stick with simplest solution – 2 string properties. It also more flexible in UI then having BiLingualString. And you won’t have to deal with Complex types when persisting.