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

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

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


oop code-duplication
person Greg    schedule 23.09.2008    source источник
comment
Не очень понял, что ты хочешь.   -  person Marcio Aguiar    schedule 23.09.2008
comment
Сложности часто невозможно свести на нет. Вы делаете реальность немного яснее :-) [en.wikipedia.org/wiki/Facade_pattern ]   -  person tovare    schedule 23.09.2008

Ответы (3)


arrow_upward
2
arrow_downward

Шаблон фасада.

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

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

Не стесняйтесь уточнять точный характер вашей проблемы.

person tovare    schedule 23.09.2008

arrow_upward
1
arrow_downward

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

person JoshL    schedule 23.09.2008
comment
Я думаю, вы упомянули здесь принцип SingleResponsibilityPrinciple. en.wikipedia.org/wiki/Single_responsibility_principle objectmentor.com/resources/articles/srp.pdf Я также написал отдельный класс, отвечающий за форматирование. MyObjectViewHelper и т. д. - person Daniel Honig; 23.09.2008

arrow_upward
0
arrow_downward

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

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

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

person Josh Kodroff    schedule 06.10.2008