Как предотвратить создание нескольких классов для одного и того же бизнес-объекта?

Question

В большинстве случаев у меня будет бизнес-объект, который имеет свойство для пользовательского индекса или набора индексов для некоторых данных.Когда я отображаю этот объект в форме или каком-либо другом представлении, мне нужно полное имя пользователя или некоторые другие свойства данных.Обычно я создаю другой класс myObjectView или что-то подобное.Как лучше всего справиться с этим делом?

Для дальнейшего уточнения:Если бы у меня был класс отслеживания проблем, и мой класс для проблемы имел IxCreatedByUser в качестве свойства и коллекцию значений IxAttachment (индексов для записей вложений).Когда я показываю это на веб-странице, я хочу показать John Doe вместо IxCreatedByUser, и я хочу показать ссылку на вложение и имя файла на странице.Поэтому обычно я создаю новый класс с коллекцией объектов вложения и свойством CreatedByUserFullName или чем-то в этом роде.Просто кажется неправильным создавать этот второй класс для отображения данных на странице.Может быть, я ошибаюсь?

Answer 1

Рисунок фасада.

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

Следует соблюдать осторожность при создании слишком большого количества уровней абстракций, поскольку уровень косвенности сведет на нет первоначальную попытку сделать код более легким для чтения.Особенно, если вы чувствуете, что просто пишете классы, соответствующие тому, что вы делали в других местах.Например, если у вас есть myLoanView, не обязательно ли вам создавать MyView для каждого отдельного диалога в системе.Отступите на 10 шагов от кода и, возможно, создайте фасад, представляющий собой многократно используемую и интуитивно понятную абстракцию, которую вы можете использовать в нескольких местах.

Не стесняйтесь подробнее рассказать о точном характере вашей задачи.

Answer 2

Один из ключевых принципов заключается в том, что каждый из ваших классов должен иметь определенную цель.Если целью вашего класса "Бизнес-объект" является предоставление соответствующих данных, связанных с бизнес-объектом, может быть вполне разумно создать свойство в классе, которое делегирует запрос описания поиска соответствующему классу, который отвечает за эту информацию.Любое форматирование, специфичное для вашего класса, будет выполнено в свойстве.

Answer 3

Вот несколько рекомендаций, которые помогут вам решить, как обращаться с этим (довольно распространенным, IMO) шаблоном:

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

2. Если у вас действительно большой класс, для загрузки которого потребовалось бы много соединений или подзапросов только для целей отображения, вы, вероятно, захотите создать класс "view" или "info" для целей отображения, как вы описали выше.Просто убедитесь, что класс XInfo (для отображения) загружается значительно быстрее, чем класс X (для редактирования).Это ситуация, когда использование представления на стороне базы данных может быть очень хорошей идеей.