Как правильно спроектировать класс, который должен содержать информацию на двух языках - PullRequest
Новая
       29

Как правильно спроектировать класс, который должен содержать информацию на двух языках

2 голосов
/ 12 июня 2011

Если мой доменный объект должен содержать строковые свойства на 2 языках, я должен создать 2 отдельных свойства или создать новый тип BiLingualString?

Например, в приложении классификации растений объект домена завода может содержать Plant.LatName и Plant.EngName.

Количество двуязычных свойств для всего домена невелико, около 6-8, мне нужно только поддерживать два языка, информация должна быть представлена ​​в UI в обоих языки одновременно. (так что это не локализация). Требования не изменятся во время разработки.

Это может показаться простым вопросом, но это решение повлияет на валидацию, устойчивость, клонирование объектов и многое другое.

Отрицательные стороны Я могу подумать об использовании нового типа dualString:

  • Проверка: если я собираюсь использовать DataAnattations, блок проверки Enterprise Library, проверку Flued, это потребует больше работы, проверка графа объекта сложнее, чем простая проверка свойства.
  • Стойкость: эфиру NH или EF потребуется больше работы со сложными свойствами.
  • ООП: более сложная инициализация объекта, мне придется инициализировать этот новый конструктор Type in, прежде чем я смогу его использовать.
  • Архитектура: преобразование объектов для передачи их между слоями сложнее, инструменты автоматического картирования потребуют больше ручной работы.

Ответы [ 3 ]

5 голосов
/ 12 июня 2011

Во время чтения вашего вопроса я все время думал о why not localization, но когда я читал information should be presented to UI in both languages at the same time., я думаю, что имеет смысл использовать свойства.

В этом случае я бы пошел на класс с однимСтрока для каждого языка, как вы упомянули BiLingualString 

public class Names
{
    public string EngName {get;set;}
    public string LatName {get;set;}
}

Тогда я бы использовал этот класс в своем основном классе растений, как это 

public class Plant: Names
{

}
4 голосов
/ 12 июня 2011

Если вы на 100% уверены, что это всегда будет только латынь и английский, я бы просто выбрал самое простое решение - 2 строковых свойства. Он также более гибкий в пользовательском интерфейсе, чем BiLingualString. И вам не придется иметь дело со сложными типами при сохранении.

2 голосов
/ 12 июня 2011

Чтобы помочь решить, я предлагаю рассмотреть вопрос о том, насколько последовательным будет такое поведение на всех уровнях. Если вы представите их как два отдельных свойства в бизнес-объекте, я также ожидал бы увидеть его, например, в виде двух отдельных столбцов в записи базы данных, а не двух переводов одного и того же свойства, хранящихся в отдельной таблице. Кажется странным хранить переводы таким образом, но ваши обоснования звучат разумно, и 6 свойств не являются неуправляемыми. Но будьте уверены, что вы не собираетесь добавлять больше языков в будущем.

Если вы ожидаете, что эта система будет несколько динамичной в том смысле, что вам, возможно, потребуется добавить другой язык в какой-то момент, мне представляется более разумным реализовать это по-другому, чтобы вам не приходилось изменять схему, когда необходимо поддерживать новый язык.

Я думаю, что баланс должен быть следующим: подумайте о вероятности необходимости настроить языки или свойства, чтобы приспособить новый язык, к преимуществу (простоте), которое вы получаете, выставляя их непосредственно как отдельные свойства, а не загружая переводы как отдельный уровень.

...