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

Question

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

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

Answer 1

Фасадная схема.

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

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

Не стесняйтесь уточнять точный характер вашего вызова.

Answer 2

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

Answer 3

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

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

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